Home / Business / Hitting the Open Source Wall 
Business
Oct
09
2008
Hitting the Open Source Wall

Hitting the Open Source WallHitting 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:

  1. Answering on the forums
  2. Writing documentation
  3. 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".
     

    Comments  

     
    #1 severdia 2008-10-09 13:42
    I think there's one more option not mentioned here that's more than #1 but less than the others. That's having the self-discipline to say to oneself that you're only going to spend 10 hours a week (for example) working on the project. No more, no less. You explain to the community around the project that you're committed to those 10 hours fully and will do whatever's possible in that time, but you life is equally (if not more) important. If the project is worthwhile, people will understand and possibly even "step up" to contribute if the pace of development isn't to their liking. Time-budgeting is a good way to maintain control of a project instead of allowing it take control of you.
    Quote
     
     
    #2 Pat Lee 2008-10-10 01:16
    Very interesting post. Other related issues to consider:
    -Are the global financial crises going to impact open source projects significantly?
    -Could there be more creative ways to design, develop and deliver Joomla extensions whilst still providing some commercial benefit to developers? (I am looking at a project whereby students at selected Asian universities perform internships
    Quote
     
     
    #3 Steve Burge 2008-10-10 08:45
    Hi severdia - I think that's a good idea also. Perhaps putting a big notice on the top of the forum saying "I'll only be here 10 hours per week" might inspire others to help. Check the reply I've added from a developer, who gives more feedback on what he needs.

    Hi Pat

    Quote:
    Could there be more creative ways to design, develop and deliver Joomla extensions whilst still providing some commercial benefit to developers?
    Absolutely! That's the kind of discussion I'm trying to get going here. Do you have more information on this project you mentioned?
    Quote
     
     
    #4 Amy Stephen 2008-10-10 09:20
    I think if a project is hitting the wall, then it's time to look at how easy - or difficult - it is for new contributors to participate and bring in their ideas, energy, and enthusiasm.

    It's not a simple task involving others. All expectations and boundaries have to be agreed upon and clearly documented. Processes must be in place to review and manage contributions of all kinds for quality and relevance and then, once vetted, more processes must be in place to ensure these contributions actually reach "the shelf." Wikis, trackers, and forums are excellent examples of enabling technologies for this purpose.

    When it is as clear "how one can contribute to the project" as it is "how one can obtain project assets", then, the necessary framework for involving others is in place and "the walls" can come down.

    Then, there are the people issues. ;-)

    "Old timers" must learn to allow new contributors time to experiment and discover, rather than discourage that "sometimes extremely obnoxious, but always, oh so powerful" enthusiasm with repeated response that ideas will fail. (Even when it's obvious that is true.) Is the project welcoming enough to ensure those who are less outgoing overcome shyness and come in? Are people at the door, welcoming them? Does the project respond promptly to volunteer offers? How about those who do not speak English? How can they contribute?

    In-fighting can be damaging or very helpful to productivity. It simply depends on the culture cultivated in the community. If conflict is ignored, cliques and gossiping begin, and focus on work will be repeatedly interrupted. If gossiping is tolerated, it is a guarantee that in-fighting will flourish and productivity will come to a screeching halt.

    On the other hand, if communities adopt an attitude that in-fighting is to be expected and respond to it as a sign of fatigue, then good things can come. All engaged should be encouraged to take time away to regain proper perceptive and the group should step up recruitment efforts. When people return, they should be warmly welcomed and everyone moves on.

    Creating an inviting, welcoming, healthy, purposeful community where one can easily come in and contribute in an area of interest and expertise, without harming what works well, is the *biggest challenge* projects face. It is quite remarkable how our open source projects are able to involve so many people from around the world and encourage their volunteer efforts for the good of the community.
    Quote
     
     
    #5 unleash.it 2008-10-10 21:17
    Good topic and one that I've also given some thought. I can see a couple solutions. First of all, open source projects that want to stay viable should work to try and change the the attitudes of users, in a gentle way. Joomla's decision, for example, to enforce the GPL is going to help keep open source in business. However, it's also emboldened the feeling of entitlement I think. People expect so much free beer, they're getting drunk! That's great and if developers either a) are retired and just doing what they love or b) don't mind being a subpar operation.

    I'm not one to think free beer of any kind is bad, and it's my choice if I want a PBR or not. Yet I think many developers are interested in going beyond that. For those, they ought to really consider the support model. Mention on your web site/forums that you will ONLY offer paid support (possibly allow users to support each other). If your software is good, people will pay. And charge a substantial amount. You probably won't become overwhelmed but even if you do, you'll be making good money. If you make too much money, hire someone else to help with support! Soeren at Virtuemart, I hope you're listening...

    Another equally important solution is to do more to attract non-programmers to help out, and listen seriously to their views. Usability, marketing, design, documentation and a user's perspective are NO LESS important than the code. This I think is really #1 and is the problem I have had in my experience working with Joomla. Joomla is now doing more with their website and marketing, but unfortunately...the team is made up of mostly programmers and can see things only from that perspective. Bottom line is, Why put a lot of energy into something when no one really cares about your input?

    Changing the situation is probably not going to happen from the efforts of any single project. But if enough get the right idea and act on it... the community will follow and watch out for the scrappy open source!
    Quote
     
     
    #6 Nikhil Parachure 2008-10-11 02:53
    Now thats not only interesting post but also a wake up call.
    From my Point of view I think there is another possible solution outside of 4 you have discussed.
    -----------
    Selling Opensource extension for marginal cost and tie ups with value added service providers for this solution like hosting.
    Lets say Bob's extension is for marathon organizers.Here are things he can try to get paid on his work and once he is confident about it he can go full time.
    1. He can charge very small amount for his extension lets say $5. A successful working example of this is Darren Gates of http://www.tufat.com/.
    2. He can have tieups with hosting companies who provide services to his clients and get paid by hosting companies in return. (I have example for this but its my own site and i am not sure if that is allowed on this blog so i can post it.)
    3. He can launch a community website for marathon organizers and marathon runners around the world and get paid big time via advertising revenues.
    While I have worked on all these solutions with moderate success, I am not a coder myself I normally hire developers to code for my company. So coders might have different perspective to these solutions.
    Regards
    Nik
    Quote
     
     
    #7 Steven Johnson 2008-10-11 08:59
    Great topic and some very insightful ideas.

    I think a solid development team with the primary dev., beta testers, people assisting with documentation etc should come first. After this there are people who do not have time to donate but can donate money.

    I have often thought about the idea of a bounty for a particular new feature. I am not 100% sure how they work in practice. Many times I think of a cool feature or have found a feature that is continually requested and the developer does not have the resources to create it. As one person I can not afford to fund the new feature myself but I am pretty sure that me and a few others could afford it together.

    It would be great if the project had an easy way for me and other to pool our money to fund the development of the new feature. After the money was raised, the new feature could be developed and released to the community.

    Again not sure if this works well in practice but it would be great for all the people interested in a new feature to work together to give the developer the resources he needs to complete the work.

    Does anyone have any experiences using bounties?

    A quick search and I found this site:
    https://www.bountysource.com/

    Thanks!
    Quote
     
     
    #8 Steven Johnson 2008-10-11 09:14
    After looking into the Bounty project I found, I learned that they closed their doors a few months ago. Maybe that answers the question of using a bounty. :-)
    Quote
     
     
    #9 Steve Burge 2008-10-14 15:09
    Hi Steven. The problem with bounties unfortunately is that they tend to be short-term orientated. Get to a certain goal and then ... you're back to the same problem. A long-term project needs a long-term business model.

    Hi Nikhil. Good ideas there. Sounds as if you're between #2 and #4, making the add-ons into a small business.

    Hi unleash.it. I agree about the widespread misunderstandin g of the GPL. I think the onus is on us (no pun intended) to explain it clearly as professional Joomla users.
    Quote
     
     
    #10 unleash.it 2008-10-16 00:08
    Yes, while I think it's the large projects that can have the most powerful effect to set standard, no doubt we all own the onus. I think all these ideas are good and can work in different situations. Like any movement that's still getting established, we'll see where the ride takes us.

    I think for projects to share a similar success as say MySql, Linux and Firefox...the little guy included...it's going to take more team work with other important skill sets than programming. But these contributors need more motivation than simply being able to use the product. Just like the developers, lets face it. We are interested in helping because we appreciate the use we get from the software, but we would also like to have some kind of say in the direction of the important tools we use.
    Quote
     

    Add comment


    Security code
    Refresh