– 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.
* I) The first issue is that even big projects depend mostly on single main developer or a handful of significant contributors. At the same time software package or program can have several million users, both private and legal entities, 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 doesn’t usually 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 jail time).
– This also 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 License, since it is in their own interest to have better insurance for LTS - Long Term Support.
* II) 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 OS software and encapsulate it into a commercial proprietary app and 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.
– The Categorical Imperative (moral implications) in this case would be those who profit the most should give something back from all the value they are getting 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 culture work toward sustainability.
– Criticism without effective solution is neither useful nor justified. 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. When setting prices avoid awkward amounts like 799, use rounded numbers, plain 800 is fine. Additionally, consider accepting Bitcoin as payment, as it aligns with the principles OpenSource Money (read previous blog posts). Prices could also be displayed in ‘Sats’ for added flexibility.
– 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).
– I call this cFOSS - conditionally Free and OpenSource Software as a middle ground between these 2 camps (relatively permissive license type with loosely enforced funding). Note that this is not like the Source Available that essentially only allows for code to be read and nothing else, almost meaningless.
– Instead, Openness is retained with freedom to use the code, modify it and distribute as a dependency (OS term is important). This enables sustainability and ensures the project survives in the long term. It gives good incentives and creates a self-reinforcing positive loop by encouraging users to give back via ‘code commits’. Additionaly, the paid ones should have simple progressive pricing tiers (based on number od Devs or some other metric). And even the top tier should not be too expensive, to be easily acceptable cost for such companies. For example, tiers could be in range from several hundres to a few thousand per year 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.
– One could argue that in the long term, all software will have tendencies (converges) towards becoming open-sourced, one way or another, since 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: The OS won.
– The entire idea is to have 2 categories of Licenses for OS projects 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 and also projects 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 it’s on their own, but be aware it is not an easy endeavor.
– 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 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
- 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