Open Source Software Weaknesses – And a Possible Solution

Open source has become a huge part of the software running on various devices. There are free open source libraries, utilities, big applications, and even operating systems! This is undoubtedly very convenient both for end users – they don’t have to pay for every piece of software they use, and for developers – they usually have to write just a tiny portion of the total code of their app or library they develop while most of the code comes from open source libraries.

Is it really all that perfect, however? Maybe, while there are clear advantages to open source, there might be room for improvement in this model, or even alternatives that will benefit end users and developers even better? In this blog post, let’s explore some of the issues with open source software, their root cause, and a potential solution.

Here are three significant problems we face with open source:

1. Low quality. While there are many excellent open source packages out there, most of the open source projects are not high quality. Since it’s very easy to publish a package, many people and companies do it, but the code is far from great – there are often bugs, inconvenient APIs, breaking changes in minor updates.
2. Poor maintenance. It’s easy to start an open source project, but it’s really hard to maintain it over time. And while there are well-maintained projects, they represent only a small part of all open source software.
3. Few people contribute to open source. There are so many skilled software engineers today who could potentially develop great open source - but most of them don’t do it.

So what are the reasons for these? Well, it mostly comes down to lack of time and motivation of engineers and companies. Everyone’s time is limited, so working on open source means not doing something else. As for motivation, let’s try to understand why individual developers and even companies do write open source at all. There are quite several reasons, here are some of them:

• Community involvement. Getting support from the community helps write the software faster and with higher quality. It also gives people a sense of belonging.
• Self-expression, reputation, and recognition. Open source showcases developer skills, builds personal or company brands, and earns recognition in the tech community.
• Contribution to the Greater Good. Many contribute to open source to give back, improve technology, and make a positive societal impact.

These are sometimes strong motivators, but not necessarily over time, and they are definitely not for everyone. Most engineers just won’t have enough time to dedicate to open source. Since open source is mostly free, developers working on it either need some kind of sponsorship to make a living from it, or have to do it in their free time. And while there are some projects in which developers get paid (by their company, by a sponsoring company, or via donations) - it’s a tiny portion of all open source. But most developers need money to live and provide for their families - so they spend most of their time working for a company, or writing some closed source that can be sold for money.

Now consider all the good software engineers out there, and imagine if they were able to write open source as their main job! The software level would probably become higher, there would arise competition moving the bars up, there would be more code sharing, and software would evolve faster. So is there a stronger motivator that would allow it? Well, yes - it’s money. If people were just paid for useful open source projects they contribute to - a lot more developers and companies would write open source. In fact, probably the majority of code would turn to open source libraries, leaving only a thin layer of non-shared code above it.

This sounds like some utopia, but let’s tackle it slowly and see if it might be possible, or what can be changed to make it possible.

First, where would the money come from? Eventually, a lot of software is paid - many end user applications, video games, online services make money. Here’s a strange thing though: most of the code used in these apps/services is actually open source, however the developers of the open source parts don’t get paid for it! Consider GitHub for example: it’s a great service, but it would be nothing without Git, yet GitHub doesn’t have to pay anything to Git developers. Sometimes companies do donate to the open source they use, but most open source contributors get nothing even if their software runs everywhere. Just imagine how many people contributed to Linux (not just the kernel) - it’s heavily used by almost any service today, yet without paying anything to the contributors.

This model of building paid software on top of free code has two aspects. One is ethical – it’s just unfair. Well, life and the world are not fair in general - but still, it doesn’t feel right. The other aspect is very pragmatic though - it’s exactly because of this model that most developers are not motivated to work on open source software - they just can’t allow themselves to not work for money, thus they will not develop free software.

So here is what should happen ideally: for every sold piece of software (in either way, including services), every contributor to the open source involved should get some portion of the profit. So if, for instance, a service A uses a library B, and B uses C and D, and D uses E - every contributor of B, C, D and E should be paid (somehow) by the company that develops A - because A is the end user service that actually earns money. In reality, the chain of dependencies is insanely huge, and every library might also have dozens of developers with different contribution values. So how, even in theory, is it possible to distribute the money more or less fairly? Well, it’s probably impossible or at least impractical without some changes and adaptations. Below are two adaptations that have a good chance to make it work.

First, since we can’t practically distribute the money in that ideal fair way to every contributor, let’s make the payments in a different way. Let’s say that every library should just decide how much it costs and should be paid by any consumer - either end user application, a service, or another library. (The price should be based on the number of users - more on that later.) If library D uses library E, then it will just make the cost of E included in the cost of D. This model leaves the decisions of how to distribute the money across the library contributors to the library owners - and it’s fine to have it done differently for every library. The important part is that for every usage of library D, it will get paid enough for its own developers and to pay for library E. And this can work transitively very nicely.

While the above solves the problem of money distribution across dependencies, it has one critical flaw: to reduce the cost (or to just pay less for dependencies), developers of library D can just put the code of E inside of it (they can tweak it a bit so it won’t be identified as straightforward stealing) - after all, it’s open source, so why not? This brings us to the second essential adaptation: the libraries should be distributed as closed source! This adaptation will remove some benefits that open source gives us today, but on the other hand, it has a chance to let us benefit from much more high-quality, maintained code than we have today.

Why paid closed source libraries are potentially a good model:

1. Many good engineers (individually or as companies) will switch to writing libraries, generating much more high-quality, shared, consumable code than we have today.
2. There will be competition between developers/companies, resulting in various options, similarly to products we have in the real world.
3. Useful libraries will be well-maintained, because the developers will be motivated to continue getting money for their libraries.

Overall, although only time will tell, it seems that there’s a good chance that this model will be much more efficient than today’s one.

There are several obvious concerns with this new model, but each of them is not as big as it might seem at first:

1. Trust. A huge value of open source is that anyone can look inside the code and check that there are no bugs or intentional malware. True, with the closed source model it won’t be practically possible. But here are some important points to consider:
   • How often does average software indeed get thoroughly reviewed? Very rarely. It’s possible to do it, yet usually people just bring the library and start using it (maybe unreasonably hoping that someone else reviewed it).
   • THE SOFTWARE IS PROVIDED “AS IS” - this is what appears in open source licences. Is it really trustworthy? With paid software however, even if it’s closed source, the license can be much more user friendly, making the developers obligated to fix bugs, to not break APIs, to validate there’s no malware in their code, etc. They will be legally responsible for bad things, thus people will usually trust their code more than open source.
   • A good library will have proper documentation and test suites covering the API - and those should be open. The documentation and the tests can help potential consumers to estimate the quality of the library.
2. Variety of target configurations. Open source can be compiled on demand for different targets, but closed source has to be distributed as compiled code, and the number of possible target configurations is huge. Although it’s not that open source code always runs well on any platform, this is still a valid concern. However, it seems to be a solvable technological challenge. If switched to this model, at first only a limited number of targets will be used (the most popular ones), and in the future there might evolve ways to either standardize targets or to build libraries for the variety of targets more easily.
3. Price by number of users. This was mentioned above and requires some more consideration. It feels that library owners should get paid according to the number of end users, or to some other quantitative measure. Solving this might be technologically challenging, but possible at least to some extent. We can also assume that usually users will respect the license - similarly to how it happens now with applications (companies nowadays rarely install free software they should pay for according to the license).
4. Piracy. People can just steal the libraries: either just use them without paying, or hide them inside their binary code so that it’s not straightforward to see that the library is used. This will probably happen, but not very much: quite the same problem is there for ebooks and movies - some people steal them, and there are some actions done to prevent it from happening. Here too, there can be some technological ways to minimize piracy, and also legal actions.

Open source has served us well for several decades, but it’s not perfect, and it might be time now to try a new way. What do you think about it? Please share in the comments!