YetiSim Blog

What makes an open source project successful? What can YetiSim learn from this? I’ve seen a lot of open source projects over the years, some rise up to great success and stay there. Some projects enjoy success for a while, then die off gradually as developers and users leave. Now that I have a blog, I decided to discuss what I think makes an open source project successful. I hope to learn from this in the construction of the open source community of YetiSim. I do not have much experience managing my own open source project yet, so I’m hoping to learn from others…. perhaps my lessons are too naive, but this is what I’ve learned regardless.

The Lessons:

1. Provide access to the source code, and have a source code management system like CVS or SVN.
2. Release early, release often.
3. Give the community of users and developers a voice.
4. Listen to your users, and pay attention to their needs. Be kind to them.
5. Provide good documentation for new developers, and encourage them.
6. A good community is a supportive one.
7. Try new paths, develop new methods. Push the envelope.

Lesson #1.

A critical component of open source software is naturally access to the source code. I have never seen an open source project that does not provide source code for download. However an equally critical component is a source code management system, like CVS or SVN. It is critical that members of the community are able to provide patches and bug fixes. I have worked on an open source project where the main developer would take snippets of code and ideas from the mailing lists, and incorporate them himself. This leads to burn out when so many people are there to help you. Also, with subversion it is simple for others to a generate a patch and submit to a mailing list. If I have to keep a tablet of paper beside me as I fix code, I will never have time to submit back my fixes. For this unnamed project I spent weeks modifying the sources for my employer, but the fixes were never shared because of the difficulty in getting the attention of the developer. The result was a stable system for us, with fixes to many problems others were experiencing on the mailing list. But they could never benefit from my hard work. Every time there was an upgrade in code from the project, I had to invest considerable time in re-applying my changes and testing. The moral of the story here, is to always have subversion access for others.  This way they can send patches to be reviewed and applied.

Lesson #2.

The catchy phrase release early, release often comes from Zach on #yetisim. It is imperative for an open source project to release something for the world to use as quickly as possible, and refine it with further development. This does not mean releasing buggy or incomplete software, this means releasing software that doesn’t have all the features everyone wants, but works pretty well. Open source software will not grow without a community, and a project will not gather a community without something for people to download and try. The released software does not have to be marked stable, which means the source is ready for prime time. The software should be ready for people to try and play with, but may have some rough edges. Projects which are hesitant to release something for people to try because the software is not yet perfect will not succeed (unless of course they are backed by corporations with deep pockets).  Also, it provides for a greater opportunity for the project to learn from mistakes early.

Lesson #3.

Give users and developers a voice. The users of a software package, and the developers of a package are equally important. A successful open source project will have methods of community communication, which might include mailing lists, bulletin boards, a wiki, or IRC. If users do not have a voice, developers cannot learn what is needed. Developers also cannot be sure they are developing something useful. Equally important is that developers are able to communicate. Projects often have separate areas for users and developers, and although this can lead to elitism, it is sensible. Developers need to concentrate on fixing issues, adding features, and learning new methods of solving problems. This can be difficult with the chatter that occurs on user forums, so it is sensible to separate to maintain concentration. A complete separation of concerns is a very bad idea, and indicates the potential doom of project. There must be a bridge between the users and developers. It does happen that a simple user question might indicate a massive design flaw, or indicate a new direction for the project.  There are usually people who decide to be the bridge themselves and participate actively in both development and user communications.

Lesson #4.

Listening to the users that you have given a voice might seem obvious, but it does happen that developers ignore their users. This can lead to elitism in the development team, and the result is a product that some people are not happy with. It is easy to say, “this is open source software, they get what they pay for.” Although I do not disagree with that statement, ignoring users can lead to users migrating to projects that satisfy their needs. This means doom for an open source project which relies upon a strong user community to succeed. There are times where users might be in error, or are suggesting something that is quite impossible with the given resources. It is okay to disregard the suggestions of a small percentage of users as being infeasible or specific to only their needs. But if a large percentage of the community wants a feature, it is time to learn what can be done to satisfy them. It is a bad idea to be stubborn about something for no reason, but quite alright to be realistic about the situation given current resources. Users are a very important aspect of a project. Most developers of a project start as users, and learn internals as they go. What I really mean, is that project developers should not ignore a feature request only because of their own objections and desire to ignore the users.  Users of software have to work with it, sometimes daily, and they often know best when it comes to features that will help them.

Lesson #5.

Provide good documentation and encouragement for new developers. Most open source projects are pretty good at this one. It is important that a project acquire as many developers as it can, and a good way to do this is to help interested developers learn as much as they can about your project. Naturally, good documentation facilitates people learning from the manuals directly. Without documentation potential developers have to post questions to mailing lists. This is not a bad thing, Google is fairly good at searching through mailing lists and becoming a sort of manual for a project. In fact most answers to questions I have about projects can be solved with a few careful Google searches. This highlights the rest of my lesson: provide encouragement to new users. This encouragement could be as simple as a thorough answer to the question posed, or words of encouragement to the user for their exploration of your project. Without thoughtful answers to questions posed on a mailing list, Google cannot help other users. It also creates an elitist group of those who are familiar with the code and those who are not. It is important to remember that tracing through the code of somebody else without documentation or help can be extremely hard. Most open source projects are good at this.

Lesson #6.

Build a supportive community by encouraging others and being helpful. This isn’t meant to be a mushy kind of statement, or to suggest that there will never be disagreements in projects. People are very important, and sometimes developers can forget that when they are under stress or are very busy. A supportive community will help attract users who are initially hesitant of trying something new. Look at the success of Ubuntu, which is extremely supportive of users. The support of other developers is important too. Finding a bug and fixing it, or trying a new design can be a very stressful experience. A good open source project is one that is appreciative of the help it receives. Some people, myself included, prefer open source development because others have the technical ability to praise your work. For me, recognition and appreciation is more important than salary.  Everyone likes a compliment or a recognition of their hard work, and it only takes a few minutes to give praise for hours of work.

Lesson #7.

Pushing the envelope is a very important aspect of open source projects. Part of what makes open source software so unique is the innovation that surrounds the projects. Anybody can download the source code, say to themselves “I don’t like this” and make radical changes that can then be tested and considered for inclusion in the main project. This type of exploration is very important, and leads to new methods and approaches. Some open source projects are open-ended, which means that they can continue to grow and adjust themselves. Other projects are simple implementations of specific things where stability is important, and the code won’t change much. The open-ended projects can explore new paths and try new things to enhance themselves. This keeps the development team interested, and the users anticipating new developments.

How YetiSim Learns From These Lessons

YetiSim is now about three months old. It has made an extraordinary amount of progress as a project in that time, although not really on a technical level. The source code of YetiSim has not changed much in the past two months, because the focus has been on the creation of a community. A wiki has been created to help potential developers and users learn about the project. This draws from the lesson of providing documentation. The source code for YetiSim is now available online for anonymous SVN checkout, and also for online browsing. This satisfies the requirement that others be able to see the source code to try it out, and to help with it. Today with the encouragement of Zach, the first snapshot of YetiSim was released, thus learning from the lesson that a project should release early. Users and developers do not have much of a voice in the project currently. I would like to setup a mailing list eventually, however this will not happen for a little while (I don’t even have email at yetisim.org yet). So YetiSim is a bit lacking in the voice regard right now.

Personally, as the main developer of YetiSim, some of these lessons are aimed at me. I have listened to Zach when he had suggestions for adjustments to the source code of YetiSim. His suggestions were acted on right away, the the code updated. I have been open to suggestions for the direction of my project, although I realize that this will get harder as the project becomes larger. I will make an effort to be supportive of users, and anyone who has questions about YetiSim. I do not have much time right now, but I certainly will make every effort possible to ensure that the project is making progress.  Of course, I will also ensure that the community surrounding YetiSim is a healthy one.