The things nobody wants to pay for
The GNU project, as described by Richard Stallman in the 1985 GNU Manifesto, looked hopelessly ambitious at the time. To many of us, it seemed that only large companies could build operating systems, and that a group of volunteers would never be able to aspire to such a goal. The volunteers got surprisingly far, to the point that, less than ten years after the GNU Manifesto was published, running a system on only free software (or something close to that) was possible. It was an impressive achievement.
Even then, though, that software not entirely devoid of corporate contributions. The X Window System, for example, was the product of a commercial consortium that predated Linux. The development of GCC was pushed forward by companies like Cygnus Computing. When the Linux kernel arrived on the scene, there was indeed a substantial body of GNU software that could run on it, but there was a nontrivial amount of company-contributed software as well.
Linux in the 1990s still lagged far behind the proprietary Unix systems in many ways, even though it was better in others. That began to change with the arrival of corporate funding, which supercharged development on Linux and on free software in general. Without it, we would not have the system we take for granted today. Companies, working in their own interest, have built up our body of free software hugely; it is almost as if this capitalism thing actually works.
The problem, of course, is that these companies have a tendency to interpret their own self-interest rather narrowly. They will happily pay to develop a driver for a hardware product, but they are less interested in supporting the maintainership and review that are needed to integrate that driver, the development of the subsystem into which the driver fits, or the support the driver will need over the years. Companies pay for thousands of developers to work on the kernel, but none pays for a single technical writer to create documentation. Work that is not seen as contributing to short-term revenue tends not to get much attention in the corporate world.
There are, needless to say, numerous other pathologies exhibited by corporations in the open-source community. These include license violations, free-riding, throwing code over the wall, and more. Projects that are controlled by a single company are often particularly problematic. These difficulties have often been covered elsewhere; today the focus is on the failure to support parts of the community that we all depend on.
Consider some recent examples of how this behavior affects the development and user communities.
In a recent linux-kernel discussion, Kent Overstreet complained
about the lack of testing infrastructure for the kernel, calling it a
failure of leadership. Greg Kroah-Hartman, instead, said that
the problem lies elsewhere: "No, they fall into the 'no company
wants to pay someone to do the work' category, so it doesn't get done.
"
He pointed out that there is not much the leadership (such as it is in the
kernel community) can do in a situation like this. So testing
infrastructure for the kernel tends to languish.
Also recently, Konstantin Ryabitsev, the keeper of kernel.org and the
author of the b4
tool, apologized
for a lack of progress with b4, observing that he has not been able to get
the go-ahead to put time into that work. He later clarified
that post: "it just means that we haven't properly reallocated resources
to allow me to prioritize tooling work
". He has a lot of demands on
his time, and b4 has not been able to rise to the top of the list.
This matters; anybody who has been watching kernel development over the last few years has seen that b4 has transformed the maintainer's task in many ways. It must have paid back the effort that went into its development many times over. The kernel community has never put the effort into tooling that it needs; the advent of b4 was a change in that pattern and one that we would all like to see continue.
One can easily criticize the Linux Foundation (LF) for not supporting this work at the level that we would like. But the fact of the matter is that the LF is about the only entity that has supported this work at all; without that support, we would not have b4. So, while encouraging the LF to more strongly support b4 is a good thing to do, it is also worth asking why no other company has seen fit to support that work, despite the fact that they have all benefited from it. The incentives that drive companies (and their managers) simply leave little room for this kind of work, even though the benefits from it would be real and immediate.
In a different part of our community, a discussion on the upcoming openSUSE Leap 16 distribution has led to fears that this version of the distribution will not support packages like KDE or Thunderbird — fears that are arguably getting ahead of the game, since they have not yet been confirmed by SUSE. Such a move would seem similar to Red Hat's decision to drop LibreOffice from Red Hat Enterprise Linux. Support from companies for the Linux desktop, it seems, is threatened.
Once again, it comes down to corporate priority setting, though with a slightly different driving force. Companies like Red Hat and SUSE (and a number of others) have supported Linux desktop development heavily for many years. But that investment is not seen as paying off. As Neal Gompa put it in the Leap discussion:
Have you ever wondered why KDE was deprecated in RHEL? It wasn't just because KDE Plasma 5 was so big that they couldn't make the jump for RHEL 8, it was also because people were not paying for RHEL for the desktop, so they had no budget for more people. It happened again with the layoffs at Red Hat last year. SUSE is no different. And Ubuntu? Canonical already did their big layoff in 2017 where they laid off hundreds of staff related to the desktop.
In many parts of the system, the work that leads to some company making money just happens to benefit all of us, even if we are not directly paying for it. But, seemingly, that path toward making money is more elusive in the desktop realm; those of us who are using desktop Linux are not generally paying for the privilege, and neither is anybody else. So the resources going into desktop development are reduced, and Linux desktop users will feel the effects of that.
Then, consider this ongoing discussion in the Python community about funding for the PyPI repository. As "fungi" put it:
Companies are unlikely to fund open source communities that are critical to their own business because “someone else will do it,” so it ends up falling on a handful of volunteers and people donating their own time after hours because they’re already being paid to work full time on other stuff.
There are few projects in our community that do not contain this kind of neglected area.
Solutions to these problems are not easy to come by. Criticizing companies for a failure to support the ecosystem they depend on can have results, but only to a point. Organizations like the LF can organize resources toward the solution of common problems, but they have to please the same companies that are paying their bills in the end. Governments can help to fund areas that the market has passed over; that path gets harder in the absence of a functioning government, which is the situation to varying degrees in many parts of the world at the moment.
If we cannot find a solution, we are likely to be forced back to our roots, depending on volunteers to do the work in areas that companies decline to fund. That can be successful, but often at a high cost to the people who are doing that work. Depending on volunteers is not an inclusive approach; there are a lot of people who do not have the luxury of giving many hours of their time to this kind of project. Progress in that world will be slow.
The community that has accomplished so much over the last few decades
should be capable of doing better than that. We have solved many problems
getting to the point we are at now — problems that few thought we would be
able to overcome; we should be able to find a way around these difficulties
as well. It will be interesting to see what we come up with.