newfoo

Earlier today I spent some time debugging an issue I was encountering with a free software package. While I searched for where the problem might lie, something interesting occurred to me. Even though the software was free in the Free Software Foundation sense, was it truly free? In order for software to be truly free, it not only needs to satisfy what FSF classifies as free, but should also lack any prohibitive barriers to modification. In this post, I'm going to examine some barriers that I've found on projects I've contributed to and provide some suggestions for making projects more accessible to small contributors.

FSF’s Definition of Free Software

To get a better understanding of what it means to be free software, I checked out FSF’s own site. FSF says that software is free if its user have:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

My particular issue today was with Eclipse. I was able to trace the problem back to some corrupt project metadata, so I didn’t need to actually dig in and fix it this time. The issue today had me wondering though: does Eclipse really satisfy freedom 3? Had my issue been due to a bug, I could probably have located the source by looking through Eclipse’s site, or maybe even google if the site is hard to navigate. But then, wait, where do I find all the dependencies for building it? After I have the dependencies, how do I actually build it? Once I’ve fixed the problem, how do I share my fixes back with the community? Granted Eclipse is a very large open source project, these things are commonly difficult for many open-source systems.

It seems to me that the more time it takes to make a first change, the less likely or free we are to modify the software. After I had my big epiphany, it made me wonder if OpenOffice.org’s apparent developer community decline could also be attributed to diminished freedom. I can’t say for certain that OpenOffice.org is still difficult to build today, but it was difficult for me to build in 2003. The difficulty in building didn’t appear to be for any lack of knowledge of the various platforms OpenOffice employed. My main difficulties were in setting up the build environment and installing Solaris’ C++ compiler (instead of GNU’s). With much effort, I was able to eventually compile OpenOffice, but not after I’d wasted a number of hours setting everything up. If projects really want as many contributions as possible, they might prioritize developer ramp-up over bug fixes and feature requests.

Really Satisfying Freedom #3

So how do we become freer to improve open source programs? I don’t intend to point any fingers at any projects here. To be honest, I’ve guilty in the past of every single one of the following suggestions in the past. Instead, here are some things we can do provide our users with more of that special freedom #3.

1. Make it easy to find the source
2. Don’t make me suffer dependency hell
3. Let me build everything with one command
4. Make it easy for me to contribute

Help Me Find Your Source

Developer will download the source if it’s easy to locate the software’s source. Lately, I’ve noticed there some fairly popular open-source projects out there where it’s difficult to find the sources for the project. Alternatively, it’s easy to find some of the source, but not all of the components. If the project doesn’t have a big download source here link blinking on the project’s homepage, it’s likely the project could make it easier to find the source.

Don’t Make me Suffer Dependency Hell

Users shouldn’t suffer dependency hell just to setup the build environment. For instance many people find entry into open-source Java projects prohibitive because of all the external JAR dependencies. I’ve seen similar problems in other platforms as well. Most large Ruby project will inevitably require its developers to install a bunch of gems before starting. Many projects are getting around this particular issue by using dependency management systems such as Maven. Maven makes downloading the project’s dependencies part of the build process. If you’ve never tried using Maven and you’re a Java developer, check out Getting Started with Maven in 5 minutes.

Let Me Build Everthing … with Just One Command!

Building the entire system should be as simple as typing: make, ant, rake, [insert something simple here] and grabbing some coffee. Preferably that command should be the standard for that project’s platform (e.g. ant & Java, make & C/C++, etc). Now, I might just be the biggest fan of one step building there is, but if it’s easy to build an open-source project, more people are likely to build it. If more people can build the software, then you have more potential people to contribute to it. I think you can see where I’m going here. To allow users to freely modify the software, they shouldn’t be restricted by a 20 minute build configuration system.

Help Me Share my Work With You

Oh yeah, contributing back to the community shouldn’t be hard either! I think this is probably the biggest barrier for me personally contributing to more open-source projects. If I’m motivated enough to fix or enhance something, I’m usually willing to slog through dependency hell and a multi-step build processes. Far too often though, I have been stopped in my tracks when it’s time to submit my work. Sometimes it’s difficult to register as a developer for the project. Even then it’s rarely instantaneous. Sometimes you can’t even register, so you have to do a weird patchset dance with a developer that is registered with the project. Relying on patchsets will add a chance that the other developer will have trouble merging in the work — especially if it’s anything substantial.

It should be easy to obtain an account on the project’s source code management repository and push contributions to a branch at the very least. If the project really wants to receive contributions, it should have a way to allow anyone to submit reliably to its source code repository with minimal effort. At the very least anyone should be able to submit patches to another branch of the project. One solution I’ve seen to the contribution problems above is the Social Code site GitHub (think SourceForge, but way better). Not only is it easy get the source code, it’s also easy to contribute source back through their simple web-interface. In fact, I recently submitted a small patch to Jekyll, the software I use to make this blog, through GitHub! I plan to write a separate post about GitHub soon because I think they’re really on to something!

Final Thoughts

All of the points I mention in this article are simple, almost silly really. If your project isn’t doing these though, you’re loosing out on a chance for a much larger developer base. By lowering the barriers for entry to your projects, your developer base will grow with a large number of people contributing small bug fixes and features they personally need. It’s likely your other users will appreciate this work too.