The two types of open source
32 points by janiczek
32 points by janiczek
Meh.
A much more useful distinction is “created to make companies money” vs “created to help humans”.
(observant readers will note that this is very close to “open source” vs “free software”, except for the fact that “free software” nowadays is more associated with “purity culture navel gazing” than actually helping humans)
Why imagine there is a clean distinction between these two things in a world where FOSS licensing is barely enforced? Plenty of things “created to help humans [society at large]” have served nefarious or selfish ends. A great example outside software is dynamite.
It’s a good question; I think part of the reason people blew off the free software movement is that they were so obsessed with licensning when as you point out, licensing will never be an effective defense against a better-funded opponent.
Plenty of things “created to help humans [society at large]” have served nefarious or selfish ends
This is absolutely true; I am not saying that the fact that it was created with good intentions in mind means that the outcome will be positive. I’m just saying it’s a more useful distinction if you’re going to classify things.
I don’t think it’s accurate to say that the navel gazing part of “free software” is some new aspect “these days”.
Normalize getting paid for open source work.
Right now, that only really happens in big and/or very successful companies. Look at people who receive sponsorships on GitHub: they get peanuts for their work. Recently, I found someone with tons of high-quality open source projects. They had sponsorships set up, and didn’t shy away from asking for them. I later found out they’re making something like $500 a month. If they were working full time on this (and I think they could), that’s $3 per hour. That’s below minimum wage in, say, Ecuador, and waaaay below what that person can make as an software engineer employee, let alone an entrepreneur. (And make no mistake, starting and maintaining a number of successful open source projects requires much of the same skill set as running a small company.)
As someone who has completely rejected the idea that we (independent developers, for lack of a better group term) should use licenses which don’t make a distinction between individual and corporate use, I have some data to contribute here:
After ~3 years of GitHub sponsors I have 41 active sponsors, whereas after ~5 months of selling individual commercial use licenses, I have 51 active license subscriptions; the majority of the latter costs are ultimately reimbursed by corporate employers, whereas sponsorships are not.
How do your “commercial use licenses” work? Do you have a subscription managing system that informs you?
It’s an honor system which leverages corporate risk aversion
So, I propose a new terminology: high-expectation versus low-expectation open source.
I probably like this distinction.
This is why I recommend forcing yourself to keep expectations low. Be very candid with your prospective users. Tell them you’re working alone, or in a small group. Tell them this is a side project. Tell them it’s non-commercial, and that you don’t plan (or even see a way) to make money from this in the future.
I think a more detailed maintenance status badge like “passively maintained” or “as is” should become a more popular idea.
You might enjoy the book “Working in Public”. The author, Nadia, takes a research oriented approach to classify projects in various ways.
The proposal here is interesting, but I would argue that there are two ways things go unmaintained: the first is outlined here in which someone releases something they don’t intend to update. I would classify this as intent. The second is: the intent to maintain it is there but either skills or circumstances get in the way. I guess that a nontrivial number of libraries out there belong to well intentioned people who, for whatever reason, couldn’t match their intentions with actions.
It reminds me of the Seinfeld sketch about the car rental. Stating an intent to maintain is the easy part, actually maintaining is difficult.
You will like this study on the “Archetypes of open source” (or the accompanying website, which tries to draw openness on a spectrum from “here’s our source code dump. Take a look but leave us alone” all the way to “we’re a co-op that votes on how we vote and our decision making, issue tracker, consensus protocols are for everyone to participate”. It’s quite interesting but a bit more complicated than what is in this article imho.
Thanks for sharing this. I briefly skimmed the doc, and found it much more nuanced than the article.
That said, I’m wondering which archetypes projects like Elm, Clojure and SQLite fall under. 🤔 Perhaps ‘Upstream Dependency’?
Some parallels with The Cathedral and the Bazaar but 30 years later the “cathedral” is not the FSF but a megacorp.
the cathedral was always a megacorp
No, it was explicitly the FSF in the book.
Quoting Wikipedia
The software essay contrasts two different free software development models:
- The cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC were presented as examples.
- The bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
The essay’s central thesis is Raymond’s proposition that “given enough eyeballs, all bugs are shallow” (which he terms Linus’s law) […]
If anything, the community around Raymond (“Open Source”) did more to enable megacorp exploitation of FLOSS software than the FSF.
Most of these issues can be fixed by just licensing under GPL licenses. The stricter the better.