LANG(jezik): Global (en-us) / Local (sr-latn)
Open-Source (img) is a great concept and movement and an excellent way to make Software more accessible and usable (check OS Initiative). It gives everyone better availability for testing, easier debugging and bug fixes. At the same time enables suggestions and improvements with contributions using PR (PullRequest) based on GitHub collaboration. But lately, that model often has its own challenges and problems due to some business practices. Some even say that Open Source is Broken. So the following proposal is an attempt to find a fix.
But first to address two major issues:
1) Single Person Dependency
The first matter is that even big projects depend mostly on main developer (one man show) or a handful of significant contributors. At the same time software package or program can have several million users, both private and legal entities, and be used in many applications. However, maintenance often becomes time-consuming with very high expectations and practically requires a full-time job.
Still, it ends up relying mostly on the enthusiasm and goodwill of the author, since there are never enough donations or financial support from the big companies. Also, paid support usually doesn’t work and is not scalable, while getting a funding like via OpenCollective is always a struggle.
Such dynamics then puts high pressure and burden on the author, leading to Burnout and abandoning the project or he/she becomes unavailable for any reason (including imprisonment).
This situation represents a risk to all users since they would lose support with no easy replacement. One well known situation was OpenSSL Heartbleed security bug, and another is log4j vulnerabilities. Also, in the long term issue for consideration is governance framework. In conclusion, it is rational for companies to pay the small fee and fund the maintainer(s), since it is in their own interest to have better insurance for LTS - Long Term Support. Selection/survival is part of software evolution process. If project grows beyond hobby scope of being a hoby it either dies or obtains proper support and funding.
2) Corporate Exploitation
The second concern is that large corporations are profiting significantly from much of OS Software while giving back very little or none at all. They take dozens of OSS and encapsulate it into a commercial proprietary app or service, and on top of that some of them make huge incomes. Which is fine as such but there should be a way to have them pay their fair share to the Engineers behind those projects.
Categorical Imperative (moral implications) in this case would be that those who profit the most should give something back from all the value they get with their business in the industry (Pareto Principle in business model). We can’t just consume open source while ignoring the cost, instead everybody should take responsibility and change the work culture toward sustainability.
Model Explanation
One constructive idea that is getting traction is to make it mostly free while keeping the source open. ‘Mostly free’ means zero cost for majority (90%+) of users, such as those with yearly gross revenues below certain limit, like 500 K or $1 million. Essentially, this approach mirrors a Dual Licensing strategy.
I call this cFOSS - conditionally Free and OpenSource Software, relatively permissive license type with loosely enforced funding. Note that this is not like the Source Available (or Public Source) which essentially only allows for code to be read and nothing else, almost meaningless (OS term is important).
Instead, Openness is retained with freedom to use the code, modify it and distribute as a dependency.
It enables sustainability (subsidizing alike) and ensures that project can survive in the long term. What’s more, gives good incentives and creates a self-reinforcing positive loop by encouraging users to contribute via ‘code commits’. Additionaly, pricing should be progressive but with simple tiers (based on number of Devs but in groups or some other metric). And even the top tier should not be too expensive, to be easily acceptable cost for such companies and proportional to the value they receive. For example, tiers could be in range from several hundreds to a few thousand for annual subscription, or alternatively to also have an option for perpetual (permanent) license. Regular funding would also make it possible to have a reward model for impactful collaborators. Also when setting prices please avoid amounts like 999 (stay away from psychology of ‘advertising’), instead use rounded numbers, plain 1000 is fine. Finally, you can consider accepting Bitcoin as payment, as it aligns with the principles OpenSource Money (more info in previous blog posts).
One could argue that in the long term, all software will have tendencies (converges) towards becoming open-sourced. The reason being is that cFOSS as business model has several advantages compared to closed source. Those include better distribution, community licenses that push bottom-up adoption, gratis marketing, etc. To frame it as: The OS won.
For sceptics, to add that criticism without effective solution is neither useful nor justified.
Ultimately we could group Licenses for OS projects into 2 categories, depending on the hardship of maintenance:
1) The first group would be fully free (MIT, Apache, BSD etc), the default for smaller projects that do not require significant time and effort. Besides initial development, later would need only occasional updates.
2) Second cFOSS type for larger and more complex projects where it becomes a burden to the developer. And if needed they should be encouraged to switch to these types of licenses (path from projects to products). Also code repositories that are from start made in such a manner deserve to be welcomed by the OpenSource community. Of course, in situations where there was a change anyone can fork the last fully free version and continue maintaining on their own, but it is not an easy endeavor.
Also to mention that distinction between ‘Free-Libre’ and ‘Free (of charge) as in beer’ camps (FLOSS and FOSS philosophy) is that first focuses mainly on Freedom but does Not imply no cost in all circumstances (it is not black-and-white).
Another interesting approach is OpenCore which in base has a core project completely free, but some premium features are paid. Personally, I am not a fan of such structure, and prefer to keep it as a single unified project - in line with the KISS principle. However, I wouldn’t mind others using it, as long as the core component is fully functional for more then half of regular use cases. Still, you can always research ideas about OS monetization - best platforms and find curious stories.
Some notable examples of projects with cFOSS license type or similar design:
– ImageSharp, – MathParser, – QuestPdf;
– EFCore.BulkExtensions - personal Flagship library (this blog post grew from the Bulk saga)
‘ (Free Community License covers most cases, only companies with $1 million+ revenue yearly need Commercial)
Finally a Recommendation for everyone would be to find a project that interests them which they also need and use, and could allocate some spare time to it. There is always a need to help with open question, improve documentation and samples, make tests, solve issue, add new functionalities and other ways of contribution. Later if you have a problem/idea make your own fully FOSS, and after a few of those one might become cFOSS or set it up as such from start.
The Rule of thumb could be that 1 in 3 to 5 projects might be significant enough to have cFOSS while others would be fully FOSS (another case of Pareto). There is useful info on opensource : starting-a-project and getting-paid. As for the companies they also can make sure Open-Source tools are safe.
More info:
- medium/the-sustainability-of-open-source
- medium/open-source-is-struggling
- medium//how-we-maintain-a-healthy-open-source
- dev.to/the-hidden-cost-of-free-open-source
- hendrik-erz.de/open-source-has-a-sustainability-crisis
- unlockopen.com/towards-a-sustainable-solution
List of all referenced Links