How do one start a successful open source project?

Question

Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.

The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.

Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"

Answer 1

You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.

If no one cares enough, it will die again. Try a different project where you do care enough.

"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.

Answer 2

This is kind of off-topic on SO, but I'll bite anyway.

Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.

Answer 3

GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.

But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.

Answer 4

I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.

Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code. There's more to it:

• Write documentation
• Create graphical elements
• Discuss features and roadmaps
• promote the project
• etc. etc.

Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)

Answer 5

Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.

Here are some observations in no particular order:

• Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on googlecode in 5 minutes and don't look back. Put your energy in features.
• Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
• Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
• Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)