Starting an Open-Source Project?

Tokimasa asks: "I recently thought of an idea for a software project that I want to undertake. I expect it to be mostly a learning experience, but I'm not sure where to begin. I'm familiar with software engineering practices and computer science topics, but I have never started a project on my own. What are the appropriate first steps to starting a new open-source project?"

Comments

Write the App first, then distribute

[fistfullast33l]

If this is a large project and you just announce that you're going to do this project from scratch, no one will be interested because it takes too long to get going. Instead, design and write the app on your own first, and then put it out there. People are more likely to get interested and form a community if they have something to play with.

If you really think you're going to need help, get a small piece working and put that out there first a la Linus and Linux.

Re:Write the App first, then distribute

[fishybell]

Exactly,

I've released/maintain three different open source applications/frameworks; Tcl PIC, UPS Print Plugin, and WyattERP. All three of these were written to be used by the company I work for. Tcl PIC and WyattERP have been used for several years, and all of them are currently being used.

I don't expect anyone to contribute to any of the projects, but people have. As long as you're giving to the community, the community will likely give back.

You must be wary of the term "Open Source Community" because no such community exists. Instead there are thousands of individual communities. Yes, many people participate in several communities, but no one participates in all, and most don't participate so much as watch. Like any good spectator sport though, it's always more fun to play than to watch :)

specifications!

[oyenstikker]

1) Requirements specification
2) Research helpful libraries and frameworks
3) Technical specification
4) Prototype
5) Realistic requirements specification
6) Research helpful libraries and frameworks
7) Rewritten technical specification
8) Revised requirements specification
9) Revised technical specification
10) Start implementation. Get portions of it working
11) Release alpha, look for help
12) ?
13) Profit!!!

Has anyone else implemented your particular idea?

[DarthChris]

There are a huge number of OSS projects, doing all sorts of things. Have you actually checked if any of them already do what you want to do? If so, consider helping them instead of starting your own - there are far too many dead/abandoned OSS projects in existence. Of course, there might be perfectly valid reasons for starting a new project instead, but you haven't given us much to go on.

How to start an open source project

[Anonymous Coward]

0. Try and pick a problem that already has a ton of mature solutions--like an XML parser, for example.

1. Set up a project on sourceforge or wherever. Try and pick a name that's very similar to an existing project or a commercial product. If you can't think of one, use an unfunny recursive abbreviation.

2. Leave the project pages empty for a year.

3. Don't do any up-front design, just jump in and start hacking code for a library or two.

4. Once it compiles, upload it to your project's version control system.

5. Make sure the Documentation and Home page links on sourceforge still lead to 404 errors.

6. When people ask where they can find the API documentation, tell them that you're using eXtreme Programming, and that there is therefore no need for documentation. Instead, they should guess what the supported API is by reading through the source code for the unit tests.

7. Code the actual application that uses the libraries and put it in version control.

8. Once you hear that someone else has worked out how to run it, call the result version 0.6 (or some other number between 0.1 and 1.0) and have your first stable release. And probably your last for a long time too. Make sure that the only documentation is a README, consisting of the generic README from GNU telling people to run the configure script and make.

9. By now, your lack of up-front design means the whole thing is a real mess. So, start doing major refactoring. Change a few APIs, and make sure that database schemas don't upgrade cleanly.

10. At this point, you might find that you still haven't managed to dissuade everyone from using your code. You can fight off continuing calls for API documentation and design contracts by mocking the other person's failure to use XP, but people might start suggesting that your project would benefit from end user documentation. So set up a blank wiki, with a home page saying "Please write the documentation for this project here."

11. Continue to hack on the code in version control, but make sure you don't have a stable release for a year or two. This will ensure that people either have to run the hopelessly outdated stable code that's full of security holes, or the stuff in the version control system that might not even compile and hasn't been tested.

12. Have another stable release, but make sure to emphasize that migration from the incredibly old previous stable release hasn't been tested.

13. Now is probably a good time to rename the project. Set up a new web site for the renamed project, with a new wiki. Migrate a handful of pages from the old wiki--enough to break the major documentation links findable in the first page or two of Google results, but not enough to make the new wiki actually useful.

14. Now you can make the sourceforge home page link point at the old home page, and give people the choice of a stable release under the old name, or an unstable release under the new name. Hopefully this will confuse them away.

These techniques have worked for many successful open source projects, including mt-daapd, typo, and half of the projects on RubyForge.