Proprietary development tools essay

This article is a draft. Out of respect for the unreleased status of this information, please do not cite or republish information here without permission. If you'd like to do so, ask by editing this page!

Many of the oldest and most important free software projects are development tools. While many of these tools (e.g., GCC, Emacs) are general purpose programming software, many have designs and features that make them particularly useful for free software development. For example, version control systems (like CVS) evolved to solve problems facing the free software development community and became optimised to support free software development over proprietary work. These tools, combined with a strong social movement and licenses like the GPL, lead to more, and more efficient, collaboration and have helped make free software a success. As code bases and development communities have grown, and grow increasingly complex, free software developers have looked to increasingly sophisticated tools.

However, many development tools designed for free software are not free. In 2002, Linus Torvalds announced that the Linux kernel would move to the "BitKeeper" distributed version control system. While the decision generated debate and consternation, BitKeeper allowed kernel developers to work in a powerful distributed fashion in a way not supported by free software tools and the Linux developers decided that benefits were worth the trade-off in developers' freedom. Three years later the skeptics were proved correct when BitKeeper's owner, Larry McVoy, revoked several core kernel developers' gratis licenses to BitKeeper when Andrew Tridgell attempted to write a partial free replacement for the tool.

Of course, free software's relationships to non-free development tools is much older and larger than BitKeeper. The source to the free software development support service SourceForge was once available to its users but its authors have transitioned away from this model. While SourceForge is built using GPLed software, SourceForge users interact with the software over the web. Because users never have any copy of the software, they can never demand source.

Both CollabNet's Tigris.org and Google's Open Source Project Hosting services serve similar purposes and keep their code similarly out of reach. Like SourceForge, the the source code to both systems remains private and unmodifiable by developers using the services. Canonical Limited, the primary funder of Ubuntu, has focused much of its resources on yet another free software development web platform called Launchpad. Launchpad offers its users an unprecedented ability to collaborate while diverging on the source code level using distributed revision control, to view bugs in related distributions, to write specifications, to submit translations for software over the web, to ask and answer and questions, and more. It does not, however, allow users to download Launchpad itself, to fix a bug in the platform, or to use Launchpad at all if Canonical were to decide that they should not.

These non-free development tools present a dilemma for many free software developers. The goal of many of these tools is, through more efficient free software development, more free software and more freedom. CollabNet, Google and Canonical each want free software to succeed and want to help it do so by making free software development more efficient and more effective.

For a series of reasons though, sometimes strategic or tactical (e.g., the company believes it must build up a "network effect" before it allows for competition) and sometimes just the business advantage that exclusivity brings, these companies choose to support software freedom through means that are less in line with free software ethics than the the ones they seek to create. The result is developers who are disempowered. The software freedom of the code these hackers produce is contingent on unacceptable exclusivity.

Software is only as free as the software it depends on for continued use, distribution, and evolution. GPL and source mean little to a user attempting to modify a program without free access to the software required to make that modification. Migrating away from dependencies, free or non-free, is always difficult.

While proprietary development tools may help free software developers create more free software in the short term, it is at an unacceptable cost. In the controversial area of private software and web services, free software developers should err on the side of too much freedom because its not just their freedom at stake but, eventually, their users and all future "downstream" developers as well. They put everyone at the whim of the groups and individuals who produce the tools they depend on — an unacceptable option regardless of the trusthworthiness of the tools' producers. To compromise our principles in attempts to achieve more freedom is self-defeating, unstable, and ultimately unfair to our users and to the larger free software development community.

Just as the early GNU maintainers first focused on creating free tools for creating free software, we should ensure that we can produce software freely and using unambiguously free tools. Any shortcoming will result in software that is, indirectly, less free. We should resist using tools that do not allow us the freedoms we are trying to provide our users, and we should pressure the producers of our development tools where we suspect it may be efficacious. Neither free software nor open source has achieved success by compromising our principles, even where some have compromised on our ability to communicate them. We will not be well served, technically, pragmatically, or ethically, by compromising on freedom of the tools we use to build a free world.