Open source appears to be very successful, but as of 2011, there are some challenges that threaten to undermine it. While it is not probable that open-source software will completely die as a result, these challenges should nonetheless be taken into consideration. This section aims to list them.
Software patents are patents that cover algorithms used inside a computer program, and prevent a competitor from implementing it as well. Software patents can often be very generic, can be trivial to think about, can have some prior art upon acceptance, and their cost of issuing and cost of patent litigation are beyond the reach of most small-time open-source developers.
There have been many cases of patent litigation in the past by large companies, and there are some companies which consist entirely of lawyers who get hold of some patents and sue large companies for infringement, hoping to make some money. The English Wikipedia has coverage of the software patent debate
Some recent anti-copyright infringement laws such as the notorious Digital Millenium Copyright Act (or “DMCA” for short.) or the more recent ACTA, can be used to prohibit the distribution of some open source software, such as those that can be used to break the copyright-protection measures of some content providers.
The Electronic Frontier Foundation has published a document titled “Unintended Consequences: Twelve Years under the DMCA”, which contains a list of “cases where the anti-circumvention provisions of the DMCA have been invoked not against pirates, but against consumers, scientists, and legitimate competitors”.
Many source code licences were approved as free software or open source by either the Free Software Foundation or the Open Source Initiative. The problem is that if one encounters a software package that is distributed under one of these licences, they will have to become aware of this licence’s peculiar restrictions. Furthermore, it will be difficult to tell whether it will be compatible with code under a different licence.
As a result, there’s the problem of licence proliferation.
Some licences are known to be incompatible with one another: the GPL version 2 with the GPL version 3 or LGPL version 3, the GPL version 2 with the Apache License, all versions of the GPL with the original BSD licence, and many other non-GPL-version-2 or non-GPL-version-3 compatible licences. As a result, often, a program that is open-source is still unusable, and will have to be reimplemented.
Furthermore, some projects or organisations may consider the software under Strong copyleft licences, or even weak copyleft licences to be too restrictive, and will instead opt to rewrite it. Here are some cases of open source code being made unusable due to problems with their licensing:
For example, the Free Software Foundation now started the GNU PDF project that is licensed under the GPL version 3, because all the other Free software PDF projects are GPL version 2 only. So because the GPL was used, the same problem need to be solved twice.
Another case where it happened was this story of an the Inkscape set operations patch:
Once before, someone had contributed a patch to add boolean operations, but that patch relied on a polygon clipping library provided under an incompatible license. There’s little more frustrating than having a solution in hand, only to be hamstrung by legal problems. Even though it was an important feature for us, we regretfully postponed development of it into the distant future on our roadmap and proceeded with other work.
Furthermore, the OpenBSD project are now re-implementing a lot of software that is only available as GPL or similar licences, under BSD-style licences, due to OpenBSD’s more pedantic licensing policy.
The GNU Project had to start working on develop the LGPLed GnuTLS because the licence of the also open-source OpenSSL library was not compatible with its GPLv2 and GPLv3 licences.
Reimplementing source code from scratch due to licence incompatibility is unfortunate, because open source developers have much more productive tasks to accomplish in their precious time. As a result, several open-source developers have opinionated that one should use a simple, non-copyleft and GPL-compatible licence, such as the MIT/X11 licence for all original source code, to encourage its reusability.
In an O’Reilly Media interview with him, back in 2005, Eric Raymond (who wrote the “Cathedral and the Bazaar” and spearheaded the Open Source Initiative organisation) has voiced the opinion that “We don’t need the GPL any more” and that people should avoid using that licence for new projects. Naturally, some people still disagree.
Some projects done by companies, or other individuals, require copyright assignment on the part of their contributors, so the copyrights will remain under the same copyright owners, who may then be able to relicense their code under different terms. Many people have been reluctant to contribute to projects that require such copyright assignment, because they would like to keep their own copyrights. As a result, this undermines the Bazaar model of development and the atmosphere of community in general.
Copyright assignment is a complete non-issue with projects licensed under permissive licences (a.k.a BSD-styled ones), whose licences allow the copyright owners, or every other party, to sublicense such a project.
There is a risk that open-source packages will become unmaintained, or spin-off a non-open-source version that will be more actively maintained. This is often seen as the risk of BSD-style licensed software, but it is not completely absent with GPLed one (see the story of the Nessus Vulnerability scanner). Even if the licence is a copyleft one, then there’s a risk of the originators of the programs stopping to update them, and no one stepping up to maintain them instead.
This problem is not specific to the FOSS world, because proprietary software also has become under-maintained or discontinued, but naturally the problem still exists.
Joel on Software describes a situation of eliminating sesame seeds:
In one of Gerald Weinberg’s books, probably The Secrets of Consulting, there’s the apocryphal story of the giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn’t hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they’re shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more.
Such a situation may occur with open-source software or free content resources, where people gradually eliminate features or text, or introduce more bugs until the software is too unusable. A prime example for such case is the so-called ”Deletionism” in Wikipedia and other collaborative online wikis, where people gradually remove pages or parts thereof that they do not like.
Another bad aspect of that is driving away the contributors who donated these features, who feel demotivated by such an attitude.
Many people in the open-source community are known for their hostility towards people whom they don’t like. I voiced some criticism of the “usability” of the Perl Online World for Newcomers, and there are similar sentiments about problems in treating people in the “HOWTO Encourage Women in Linux” document. I’ve also witnessed how one very important open-source project, which I was involved in, stagnated, because its developers were incredibly rude on their on-line forums and scared away most potential contributors.
Such hostility may be detrimental to a project’s success or the success of the open-source community in general.