Easy question: I get a paycheck every other week from my employer, Red Hat, who pays me and thousands of other people to build, maintain, and support enterprise open source software.
Are they still paying peanuts? I'm actually surprised more companies haven't take advantage by poaching from Red Hat. It's pretty much a free opportunity to get some decent people on the cheap. And it would still probably be like 2x bump for most people there. Or more, depending on location.
A Python script is not the answer when I'm trying to do something quick and dirty at the shell.
The beauty of shell scripting is that it evolves seamlessly from trying to solve simple problems at my command prompt. I pipe a couple of things together, and then I realize I could use a loop and a few conditionals, and suddenly it makes sense to store this in file in case I want to do this again. Boom, program done.
It now works on every computer I own.
I love Python. I use it almost every day. But I'll be damned if I'm going to go rewrite every shell snippet I hack together into Python just because it exists.
Your observation about the seamless evolution of a basic shell script from a few lines typed interactively is very insightful.
This kind of automation adds a lot of value for low marginal effort and probably explains a lot of the short scripts I have laying around in directories.
True that. But everyone should keep in mind that script bloat is real. If you're not careful you'll end up like me, and accidentally have to maintain what is essentially npm but written entirely in bash.
Not intentionally picking on Listmonk (or you), but when I hear "alpha-quality code" and start thinking about the complexities of marketing emails with GDPR, CCPA, and the constant threat of blacklists and otherwise getting blocked by big G, I run for the hills.
> Arvind Krishna was "Jim Whitehurst's boss" until now
Not true. Jim (and Red Hat under him) reported directly to Ginni. Red Hat was under IBM cloud for revenue reporting, though, but the distinction is material.
I assume if the entire world is spending billions of dollars reworking culture, infrastructure, software, etc., that swapping to making weekly pay the norm is just a bit of noise in that transition.
I wonder what the gamification effect would be if we paid everything by the second. I think for example transitioning from social support to employment would be more attractive.
Switching everything to any other system all at once would indeed be a huge waste of money.
Our system: I make more, and I pay for the biggest expenses (mortgage, and previously cars and student loans before we paid those off) and have healthcare and whatnot taken from my paycheck.
She makes less but still a decent amount and pay for the smaller bills.
Every once in a while, she'll pay for a big-ticket item (like a vacation or a large house repair) out of her savings, which accumulate faster than mine, to catch up.
It works because we started together with next to nothing, so we're both big savers: Our combined income our first year together after college a little over ten years ago was probably a quarter of what we'll make this year. We both max out (or come very close to maxing out) retirement now. She has more cash on hand because I'm paid proportionately more in various types of stock incentives, so when my incentives vest I tend to sell the company stock to diversify but keep the money in investments).
We live in a small house, no kids, reasonably cheap cars, vacations are often tacked on to work trips to save money, no expensive hobbies.
I doubt I'll "retire" early but our savings mean if I decide to leave tech in a decade and become a woodworker or park ranger, I can with no monetary consequences.
Totally freelance? Not sure. Small teams doing custom site development? Absolutely.
I've seen large companies pay six figures to stand up a microsite, the kind of thing that one person could easily put together in a few weeks.
The catch is that you don't necessarily have a few weeks, you have a few days to go from concept exploration to go-live. It really becomes more about project management than web development in these instances, having a network who you can turn to quickly when you need more hands on deck.
And though I hate the phrase "full-stack" because it means so many things that it sometimes seems like it means nothing, they do really expect a well-rounded technologist.
I'm working with a consultant right now on a web project for my employer. I talked to him yesterday about IE11 fallbacks for Flexbox, proxy setup, CDN configuration, logging and metrics, debugging a custom legacy spaghetti-coded marketing-tech JavaScript, modifying a Drupal PHP module to support project-specific requirements, configuring cron, and a handful of other things, and I fully expect when I talk to him today he's going to have all of those tasks finished.
Those people are invaluable. Someone who can write a little HTML and CSS and maybe stand up WordPress? I'm sure there are jobs for that, but I don't have any need to hire them as a freelancer because I expect everyone on our staff to have those abilities.
That said, doing freelance web dev is _exactly_ how I got my foot in the door with the job I have now. But it paid squat for the time I was doing it, and I hated it because my time ended up being 50%+ of the time running the business side of things instead of building website, which is the part I actually enjoyed.
We have the open source licenses we do for a reason. They've been vetted. They work. They meet established criteria. It's okay to consider new ones, but the process for that isn't just to make something up and hope it works.
Amateurs have no more business playing lawyer and writing general-purpose software licenses than they do playing doctor and handing out surgical advice. It's not thought-provoking, it's dangerous and harmful to people who don't understand why licenses like this could cause them huge unmitigated legal headaches down the road.
> Amateurs have no more business playing lawyer and writing general-purpose software licenses than they do playing doctor and handing out surgical advice.
It’s worth noting that the creator of License Zero is in fact an actual lawyer. And he has been working on open source license issues (and blogging about it excellently) for many years.
> Amateurs have no more business playing lawyer and writing general-purpose software licenses than they do playing doctor and handing out surgical advice. It's not thought-provoking, it's dangerous and harmful to people who don't understand why licenses like this could cause them huge unmitigated legal headaches down the road.
No, that opinion is fear mongering and damaging to a functioning democracy. Legal contracts are a foundational tool of modern democratic society. To say laymen should never write contracts means to say we should also give up valuable tools to make our lives better. Who do you think wrote the original GPL? According to Wikipedia Stalllman wrote it [1]. I bet many legal experts of the time wouldn’t have recommended the idea of copyleft or perhaps even condoned writing it. Having laymen initiate the contract writing process also helps put pressure to keep contracts in "plain language" as some advocate for [2].
To be clear, one _really_ should have a lawyer familiar with relevant legal jurisdictions to review anything written by a layman (especially oneself). However, it’s important for people to take active roles in the legal process lest it become the sole domain of lawyers. One example I’d construe is as a layman "writing (part of) a contract" would be a new employee requesting a change in an employment contract to change an overly broad IP assignment (say excluding after hour open source work in areas outside the businesses domain). It’s common for companies to just use whatever boilerplate employment contracts their contracted lawyers copied out of some off the shelf contract regardless of how it fits the business or employees.
RMS had a local Boston area lawyer help with GPL. I can’t remember the name offhand, but they’re still in practice, albeit not so much in open licensing.
I’d agree that Prosperity is not an open source license, but I still emphatically maintain that Parity is.
Moreover, the arguments against them I’ve heard haven’t been based in lack of free distribution or OSD 1. Anyone is free to redistribute Prosperity- and Parity-licensed code.
Amateur is ad hominem, and also simply incorrect. I won’t pretend my views are consensus, but I have spent a lot of time with OSD, and the result has been disappointment, not reverence. See:
> I’d agree that Prosperity is not an open source license, but I still emphatically maintain that Parity is.
It's very clearly not.
> Moreover, the arguments against them I’ve heard haven’t been based in lack of free distribution or OSD 1.
While I see arguments on OSD 1, I’d agree that's not the clearest problem. Clause 3 of Parity runs directly contrary to OSD 9. (Oddly enough, Parity might just be the odd license that manages to be a Free Software license without being an Open Source license, though, as the Free Software Definition doesn't have anything equivalent to OSD 9, even though the two definitions usually either both fit or both don't fit licenses.)
> Amateur is ad hominem, and also simply incorrect.
You're right. I do owe you an apology for that. Sorry.
I still find the circumstances _around_ license discussions like this to be filled with a frustrating amount of amateur lawyering that can be misleading and dangerous. As an open source developer and content creator, I can't tell you how many times I've come across something in GitHub with a "clever" license and thought "great, now not only can I not use any of this, but I see a whole contributor community who clearly believe they are contributing to an open source license when they very much are not."
> I still find the circumstances _around_ license discussions like this to be filled with a frustrating amount of amateur lawyering that can be misleading and dangerous.
I could not agree more. Except that I'd blame the lawyers, not the amateurs. There will be amateur discussion, because there are far more needs of the kind than affordable and available lawyers to serve them. If the level of amateur discussion bothers lawyers, the lawyers should raise the level of amateur discussion.
Gregg Toland famously told Orson Welles there wasn't anything about the camera he couldn't learn in half a day. That's true of law, too. With a baseline liberal education, if you put in enough days, you've got it. From there, you develop by immersion and participation. Simple as that.
I do what I can. With plain language. With public writing and participation in public projects:
> To be absolutely clear, neither of these "License Zero" licenses are open source or open source compatible in any way whatsoever.
Which may be why the author coins the misleading, sound-alike marketing term “open software”.
Though I’m not really sure what, if anything, the point of that long, meandering, piece was. It occasionally seemed like it might be circling in on making a clear point, butnthent drifted off in another direction.
I neither coined “open software”, nor do I think it misleading.
Quite the contrary. Until the recent release of the Blue Oak Model license, with which I was also involved, I don’t think there had been a legally rigorous license as easy for non-lawyers to read and apply than Parity.
How easy a license is to read and apply is not relevant to whether it's an open source license or not (and personally, as a non-lawyer, I've also found the GPL to be very easy to read).
"Open software" is not a term of art in the free software community (only "free software" and "open source" are), which makes its similarity to "open source" seem quite suspect. And maybe you didn't come up with it, but that doesn't mean it's not a misleading term.
Readability goes to whether a license is misleading. The more readable, the less potential to mislead, assuming effect isn't compromised for it.
If you found GPL easy to read, v2 or v3, you join a list that as far as I know includes no active open licensing lawyers. Of all the major, painful, routine questions about open license compliance, those from GPLs outnumber all the rest.
Getting through the text is one thing. But that alone is not what I mean by a license being readable. In substance, rather than form, it has to be a functional set of rules.
If by term of art you mean defined with precision, neither open source nor free software meet that standard, unless you count definitions that say "whatever such-and-such organization says" or "whatever such-and-such organization's founder says".
The OSD may be readable for you, but only in the way GPL was. There's no legal or otherwise technical precision beneath those pleasant terms answering old, important questions.
> Readability goes to whether a license is misleading.
Nobody said the license text was misleading. The point is that the use of the term "open software" is misleading because it leads the reader to think it's similar to "open source" which in fact isn't.
On the topic of precise definitions, you might argue that "open source" is imprecise because it has other meanings and was in common use before OSI. But "free software" was a brand-new term and has a specific definition (the four freedoms). The DFSG are guidelines and tests to verify if the definition is followed.
The four freedoms, or What is free software? on fsf.org, are even less precise than the Open Source Definition. None of those is an effective "test" in any technical sense. Frequently, debates about whether licenses "pass" them turn into debates about what the words of the test mean, rather than what the terms of the license mean.
To give a sense, FSF says "four freedoms", but they actually require at least five. The fifth (number 4) is the right to make and share nonfree work based on free work within organizations, known as "private changes". FSF writing doesn't explain the boundary between running and changing, or why free software licenses can set conditions on changing, but not running, or why AGPL gets to break that rule. They don't explain how anti-Tivo or anti-DRM satisfy the freedoms.
Readable licenses are important because they cut the welds on the hood of software licensing. Devs can read Parity or Prosperity or Charity or Blue Oak and decide for themselves whether it's open or free or public or simply allows them to do what they want to do. They don't have to trust intermediaries, who it turns out apply unexpressed, private views on what the definitions mean as or more often than expertise on what the licenses mean.
As for Parity and strong copyleft generally, consider:
> I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code.
Copyright has given authors broader and stronger control of their work in the last three decades. Why haven't FSF copyleft licenses gotten correspondingly stronger?
We're still hiring, by the way.