Bazaar or Bizarre
I recently came across this critique of Eric Raymond’s The Cathedral of the Bazaar by Dr. Mark Tarver. I started off pretty skeptical as I was familiar with The Cathedral and the Bazaar from many years ago. At that time, Microsoft was still dominant and it was clear that their ever-expanding, monopolistic, closed ecosystem was not the path to better software. Open source was still fairly new and fighting to prove itself. My uncle worked in IT at a big, old enterprise and said they were forbidden to use Linux or other open source because no one was on the hook for its quality. Although Eric Raymond seemed like a bit of a wacko, I found myself convinced by his essay about why open source could produce better software than closed source.
Time has passed. Open source is no longer fighting for acceptance. It’s nearly the opposite now, where any software that isn’t open source has to justify itself. Critiques about the open source model have been growing, but most of what I’d heard so far was that we needed to find a way to offer better compensation to the maintainers for the work they are doing. I am sympathetic to that, but what really struck me in Tarver’s examples of open source failures was how much work isn’t being done at all. Of course we need to compensate people who are maintaining open source, but what I hadn’t connected was just how much real software is out there being used but not maintained.
Consulting with Leema?
This got me thinking about how Leema might be reliably funded (should the need arise lol). I work on Leema because it’s fun and challenging, not because I’m expecting it to be a huge commercial success. To the extent that there’s ever been a “business plan” for Leema, it was that if some companies used it professionally, maybe they would hire me to consult for them.
Such a plan might work for me, as the author, and maybe a small number of other maintainers. It probably wouldn’t be especially helpful for more occasional contributors or bug fixers. And what about library maintainers, the people who make a language usable and build a healthy ecosystem to support a language? There again, a few people might find jobs in consulting, but just as in the many examples of open source failures in other languages, most library developers would be volunteers.
A Business Plan For Leema
Is that really the best we can do? One tenet of Leema is that languages should do more. An example of this is to bring the failure type into the language so that failures can be given special treatment. Could a language do the same for open source funding?
Imagine if a language was licensed so that it could be used freely in development or non-commercial use, but would carry a fee if used commercially. Consider a fictional scenario where AcmeSoft is using Leema for a new website. As the language, Leema knows which library dependencies have been downloaded and included in AcmeSoft’s project. It can also know whether it’s running in development or production mode and how many CPUs are in use. Let’s say that based on usage, the fee for Acme Software is $25/month. Because we know which libraries are in use, that $25 can be split and distributed out to the authors of all the libraries. The more commercial projects that use a particular library, the more that library’s maintainers will earn each month.
The goal would be to keep fees for any company fairly small relative to their usage with the hope that most companies would be willing to pay it if it meant consistent improvement and maintenance for the software they depend on. Maybe it’s a bit like tidelift but integrated directly into the language and universal for all libraries.
Plausible?
Sure, it’s probably a long shot, but Leema is a longshot anyway. If anything, an approach like this could help Leema gain traction with library developers hoping to build a successful web framework or ORM library. And the better a language’s libraries, the more likely it will be used.
leema 