Slashdot Mirror
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?"
No one cares about your LAMP powered digital picture archiving system.
1) Open development environment of your choice
2) ???
3) Profit!
First, familiarize yourself with the GNU public license (why this is important will be discussed later.) Second, model your life after a combo of Bruce Perens, RMS and Eric Raymond. Try to pick all the best traits of each one. For example, follow RMS's grooming standards and eloquence, use Raymond's ego and the high and mightyness of Perens. After you have done that, head down to the nearest bar and try to pick up some women. This is where familiarity with the GPL comes in. Women love to hear about it (at length.) Once you have the women, then you get the power or something like that. This will lead to a life a riches and happiness. Oh, and open an account on source forge, put up a description and don't update it for at least three years if ever.
Good luck and happy coding!
Wow - that's loads of effort! I just set anonymous and funny to -5 and that's that. I don't trust other people's opinions of what constitutes a troll or flamebait, mainly because I've seen many good posts moderated as such. People don't seem to moderate serious, sensible comments as funny. If you're anonymous, then don't bother posting. I utterly fail to understand the argument that some people have to be anonymous because a post might come back and bite them, because to believe that you'd need to also believe that such people are incapable of coming up with a nickname.
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.
moderate parent up!
Be wary of any facts that confirm your opinion.