Hitting the wall:
“In endurance sports, particularly cycling and running, hitting the wall describes the condition when an athlete suddenly loses energy“. (via Wikipedia)
Hitting the open source wall:
“In building a project, particularly when giving it away free, hitting the wall describes the condition when an project suddenly loses energy“. (via me)
This is a problem I see more and more, and I wanted to give it a definition. What happens with an open source project outgrows the time and capabilities of the original developer?
Let’s take a guy called “Bob” as an example. He has a good job outside of the Open Source world. For fun, in his spare time, he writes code and develops “Running”, an extension to track how many miles he runs every evening. He releases it to the community and puts up a forum to answer questions. For the first year, he’s delighted to see that people find his extension useful. The second year “Running” becomes widely known and traffic on his forum really picks up. He find himself spending 20 or 30 hours per week answering questions with another few hours for fixing bugs and adding features. In the third year, things really get crazy. Marathons and races all over the world start to use “Running” and every time he logs on there are a hundred new questions waiting for him. People don’t take the time to read the documentation he’s written or search the forums. A few people donate time or money, but not enough and by now the workload is up to 40 or 50 hours per week. New features grind to a standstill and the Bob feels burned out.
I’ve spoken to several people with this problem and heard of plenty more. Lots of projects are hitting the open source wall.
Solutions
Problem defined, let’s look at some solutions:
1) Do nothing
Outcome: Both development and support slow down. The developer wonders why he started this project in the first place and may quit.
2) Start selling support, documentation or small add-ons
Outcome: This becomes a slightly more satisfying version of #1. The developer doesn’t get any more hours in the day, but he/she is compensated a little.
3) Recruit more developers
Outcome: If done correctly, this can be a successful way around the wall. However, it does bring problems with vetting, organizing and co-ordinating the new project members and the developer can feel more like a manager than a coder.
4) Go Full-Time
Outcome: Either the developer finds income by charging for custom work on the extension, or by taking it fully commercial. The potential downside is that the original code was probably GPL and the developer needs to add a lot more features to make his new version special.
Finding a Way Around the Wall
I really feel that a lot of open source projects have hit this wall. Getting around it is the biggest problem they face and many never make it. Essentially we’re looking at a “Good to Great” problem for the open source world. There are several different ways that developers get around the wall, but too many seem to be trapped by their success rather then enjoying it.
Over to you. I’d love to hear your thoughts on the best ways for open source projects to grow …
Update From One of the Developers Who Inspired This Post
“Responding to your third point: I don’t believe recruiting new developers is the problem. Most projects don’t need new developers. The amount of programming in most extensions can easily be handled by one single programmer. What these projects really need are people helping in three areas:
- Answering on the forums
- Writing documentation
- Beta-testers
The coding is the nice part. In fact, its not so much coding as it is researching and designing new features. That’s why I started my project and its what keeps me going despite the other hassles”.