How to get a succesful open source project:
The beginners guide.
Well, you’ve developed a useful piece of software for your own needs and you want to share it with the world. Or, you have a great idea and going to implement it in a collaboration with other interested parties. Or, to be more prosaic, you did an initial software implementation, but realize that you have no resources to push it through to a productional quality stage. Anyhow, the best what can you do is to start an open source project.
Above all, have no doubts — you’re on the right way in any case. Your home-made software will be recognized by the whole world. You will see how your brilliant ideas are evolved and implemented into the new technologies and software applications. And you will get high-quality software for your needs without hiring a team of high-paid professional developers, managers and beta-testers. You will get a lot of new friends around the world, an experience in software design and development, a fame and reputation (and maybe a money, why not?). In addition, sharing your ideas and software code brings a great moral satisfaction and it is a good practice to improve your karma.
Starting and initial arranging the project is easy and with free hosting services, like at SourceForge, you don’t need anything except for few hours of your time. It is much harder to have success with that project.
Obviously, your software should do something useful for other people, but it is ultimately not enough for the project success. Your efforts on developing an initial code is only a start point of your path and there are numerous traps and rocks on your way. It wouldn’t be so, if only there were no interesting and promising free software projects which were unfortunately failed because of some flaws in the process itself.
This article contains my observations about how to get a successful opensource project. This is a summarization of my own experience on starting, leading and participating the free software projects (including my mistakes and failures) and of analysis of succesful opensource software. Also, the content of this article had a strong impact of explorations on social aspects of the opensource phenomenon made by Eric Raymond (read his classical essay “The Cathedral and the Bazaar”  and other articles to be up on the question) and Moshe Bar & Karl Fogel — authors of the “Open Source Development with CVS” book , which is not only a CVS guide, but also a great source of helpful ideas on opensource development process.
What is a succesfull project?
You can say a project is succesful for you if it matches your personal goals and expectations. Right, but this is only effect of success – it is your profit. The criteria of success is mainly the same as for any (commercial) software: the project has a high-quality and popular product.
Commercial software needs for investments – and open source too. But this is not money investments – this is labour and time of the project contributors. When someone develops a software design, does coding, testing or documenting, he or she invests her labour into the project. So, the project should be attractive for investments and continuously obtain this kind of funds.
The only vital condition of open source software success is community.
Linux is so successful not only due to the brilliant ideas and their implementation, but to effective development model attracted a high-quality labour of a lot of skilled Unix hackers worldwide. Linus’ initial code was a great thing, but it would never be the today’s Linux system if there were no collaborative efforts of many people around the world. A reliable and productive community of highly interested and enthusiastic volunteers is a main capital of an opensource project and the key factor of its success.
That’s the point — to run a succesfull project it is not enough to be a talented coder and software designer. Since you’ve released the project, you have to get some, probably new skills — such as marketing, PR and even poitics. You should learn for collaboration, effective team management and ability to inspire the people.
Be straight in your intentions
Don’t be untrue. You’ll get other people joined in a project only if they’re sure they contribute into a real free software. You can do your best to straightly declare a free nature of the sourcecode if you’ll put it under an opensource software license.
Provide true information about you and your goals in the project. Don’t conceal himself behind a nickname — this is a habit of stupid crackers and may arose suspicion. You do a fair job and your real name worths a respect and fame.
Choose an appropriate opensource license
Depending on your goals, you can choose one of the opensource licenses:
- The GNU General Public License (GPL). It constraint anyone from making proprietary closed-source product derived from GPL-licensed software. Use GPL when doubt.
- The Lesser GNU General Public License (LGPL). The variant of GPL created specially for software libraries. It allows to use LGPL-licensed libraries in proprietary products (the GPL itself does not permit to do so).
- “BSD-like” licenses, such as BSD (Berkeley Software Distribution) License, or The Apache Software License. The licenses of this kind doesn’t prevent to make proprietary products based on your code. They have relatively few constraints — mainly, concerning required mentioning a copyright of original author in derived products (proprietary or free) and prohibited usage of the original software name.
- The Artistic License. The GPL-compatible license adapted by PERL community.
- The Mozilla Public License (MozPL). It discourages of making proprietary derived versions, but allows to create proprietary add-ons.
Of course, you can invent your own software license, but in this case new users and developers will be forced to spend their time for examine its terms and you’ll, perhaps, be asked for a lot of questions. So, do not complicate the things and choose one of the well-known OSS licenses.
Publicize your project
If you think opensource software doesn’t need advertising, you are quite wrong. Don’t be diffident and stingy on advertise your project. The more people will learn about the project, the more chances you get to enlarge your community. Announce it in the blogs, mailing lists, forums, newsgroups and among other network communities. A direct mass mail to people involved in the same area may have a good effect also. Maybe, you’ll get a few replies blaming you for spam, but if you’ve selected the right target audience, the most of the people will be happy to learn that something new is appeared in their area of interest.
Motivate users to contribute
The users of your software is a primary source for recruiting new project members. There already is a kind of the “power users” who enjoy to play with a program, hack it, customize it and try to improve it. They are the best candidates for new developers.
Let a software to be attractive for improvements. It is not that you should make it intentionally buggy and ugly (though, every initial release is buggy and ugly anyway), but it should encourage users to make it better from point of view of their experience and preferences. National localization, user interface skins, pluggable features, scripting and other sugar are effective attractions to explore the software from a backside and start to contribute.
Cultivate your community
Encourage people to contibute into the project. In fact, working in a friendly collaborative environment is one of the powerful motivation to contribute for many people. Keep this athmosphere of good will, collaboration and common understanding and your community will only grow.
Don’t let the people feel they do something personally for you – this is ultimately not the case since you’ve published your code. Let them feel this is their project as well as it is yours — and this is really so. Don’t turn your authority as an initial developer and project maintainer into dictation. Remember Tao: “If you want to lead other people, you must put their interest ahead of your own”.
Respect other’s opinion and try to answer personally for every feedback. Above all, pay your attention for constructive, argued, technically proved suggestions with designated ways of solution. Follow the same style in your own postings. Put important decisions concerning the whole project to discussion and voting. Besides of the well-known fact that the collective brain-storming brings the better solutions (the “Delphi effect” ), this is also an opportunity for everybody to feel a value of her personal opinion.
Don’t ask the people to contribute and don’t make them feel any responsibility for it. For a lot of people it is just a fun and you have to value this attitude, because fun is a great driving force. In fact, a big deal of outstanding serious software has been made for fun. For many developers the project is an opportunity to do their favourite job without deadlines and bored managers. Such spirit of fun, freedom, ease and enthusiasm is the best athmospere for opensource communities. Do your best to keep this spirit, cultivate it and be actively involved in it.
Don’t hurry the people. If you granted a commit privileges, don’t expect for continious active contributions and don’t rob the access privileges back even if a commiter is inactive for a long time. Instead, try to inspire the people by your own enthusiasm. It is experienced that the project activity grows (and falls) exponentially — the more people are involved in active development, the more people get motivated to be involved too. It may sounds like a paradox, but lack of deadlines actually doesn’t slow the development process. In fact, many opensource software is developed faster than their proprietary competitors, although the most part of developers doing it in their spare time. I think, the reasons of such phenomenal productivity are ?pen nature, freedom and enthusiastic spirit inside the team – the things which are hardly reachable in the corporations. As far as I know the programmers, they are very hardworking and sedulous people, and the opensource is an ideal environment for exposing these habits.
When once you feel your project lives by its own life and is no longer depended on your personal will and efforts, this is a great milestone. If you were away for month or two, then got back and discovered that there are new version releases and project members, be sure you’ve reached your goal to create a succesfull project community.
Cultivate project reputation
Cultivating a community is not that you should please for everybody and turn the project into a public amusement. After all, the goal of the project is to develop a software, but not to have fun in a community. The project have to have the certain direction and the project maintainer is responsible to keep it on track. Be able to say no when it is needed. Use your authority for judgement and rejecting the features which are definitely out of subject but always provide a reasonable argumentation and be polite. If you’re in doubt, put the question to public discussion.
Before granting a commit access to the repository, imagine yourself as an employer hiring new workers. The internet users are just the reflection of human society and don’t be surprised if you meet not only intelligent and skilled developers. There very well may be the people from a well-known and ubiquitous tribe of “enthusiastic fools” who can smash the whole code base by very kind motivations. Despite all their demolitions are easily recovered with versions control, it is better to recognize such people on very early stage of their activity (fortunately, it is easy) and keep them at a safe distance of the repository. Also, be suspicious for anybody who doesn’t reveal his real name and email address. Grant commit access for well-known community members who have already been proven as the authors of helpful contributions. It is not that somebody is able to make an irreparable harm to the product or to the project infrastructure (as it was said, it is all recoverable), but hurting the project reputation is much more important thing.
Cultivate project leaders
You cannot guarantee you will maintain and coordinate the development during all the project lifetime. You may get uninterested and get busy on something new, or one day you’d realize you did all your best for this project. Actually, many opensource projects are led by the followers of initial developers.
When your project have a stable and reasonably large community, invite few responsible and active commiters and ask him to share your project’s admin privileges. You will make your own maintainer’s life easier and should be guaranteed the project coordination will be in reliable hands when you’re gone.