Starting an Open-Source Project? 94
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?"
A Few Tips (Score:5, Informative)
Build a first stable release with 80%+ features (Score:3, Informative)
Re:A Few Tips (Score:5, Informative)
What for?
"Setup Trac"
What for?
"or use Google Code Project Hosting."
What for?
*FIRST* you START thinking about a very gross app design you really want to see in existance and really want to use yourself (I'm with the one that said that having such an app and *not* having to develop I myself would be the real triumph).
Then you look on the Internet for an open project that could be developed towards your own goals.
*IMMEDIATELY* you start CODING and sending patches to such project.
You stay sometime coding on said project. With enough luck you won't need to start your own project. Starting your own project so you can say it's your own project only shows lack of selfsteem.
Only if after some time collaborating to that project (you must show to yourself you are able to code up to other's standars and that you are able to colaborate with other people on a codebase that maybe you don't completly know/understand) you find there's no real perspective for the project to achive your desired goals you think about starting your own project.
Then again you start it by a gross desing (your experience on the previous project will help you a lot here) and immediatly start *CODING*.
Only when you have some code that does "something" on proper fashion (better if it's something innovative, not another half-assed LAMP photoalbum, please) you use your usual Internet communication channels (maybe a newsgroup, maybe some tech blog you use to visit, maybe the previous project your worked on mail lists) to announce your "something". On proper time, if your "something" is of any interest, your home ADSL won't be enough to cope with people wanting to download your code.
Only *now* it's time to open a project within freshmeat, sourceforge, berlios or some other place of your preference (if you don't have a preference maybe it's time now to do some research about them. Do not lose your precious time doing it before you need it: just code).
Some time after that, if you're not bored yet (your previous participation on another's project will serve you to test your strength) and your pet project gains some other commiters, the time will come to some reads about producing/managing open projects/open communities. Again do not lose you time doing in it before you need it (and you won't need it while your project is a "solo show" or you have less than half a dozen commiters).
When/if your project gains momentum and you learn how to manage it, time will come to enterily rewrite your app (what? did you think your first model would be "the right one"? You fool). Opinions from both users and your other committers will point you towards proper toolkits/proper design/ proper functionality. Just don't forget those opinions are *very* valuable but now it is *your* project and it is *you* the one with a goal.
If you follow these steps in the proper outlined order your project maybe will be the one out of a hundred that goes beyond the "half-assed petty project" stage to become a real "something".
I really desire you bests of lucks.
Despite what you may have heard... (Score:5, Informative)
There are a number of reasons why starting from scratch can be a good idea:-
1) You'll have a codebase which you'll understand, rather than having to try and comprehend someone else's, which is the product of a brain and a range of experience other than your own.
2) You can be sure said codebase works, because you'll have been able to do your own testing, overseen by you.
3) Often earlier implementations of a particular idea will be written in a technically inferior, less stable, less secure way. This is very often the case with the "Linux must at all costs be an imitation of Windows" crowd in particular. The old saying that if you want something done right, to do it yourself, is even more true in the case of FOSS than in most other areas.
4) (This is probably the single most important one) If your project runs on Linux and becomes popular, sooner or later the GNU zealots will come to call. These are people who are very anxious to make sure that you're "giving back to the community," and that you aren't "taking advantage of your suppliers for your own gain." They do this primarily because they seek justification for being able to dominate others. Starting your own codebase means that you will have the right to experience the intense pleasure and satisfaction that may come from demanding that these individuals commit suicide, preferably in the most agonising way possible, at the earliest possible opportunity. If you start your own codebase, you don't owe anyone else anything, and you can tell the zealots that. The detestable, leftist zealotry exhibited by the reciprocity police is one of the strongest arguments against the re-use of open source code in new development projects. If you don't use anyone else's code, you can make sure that you are able to avoid the above...and to me, this reason alone is justification for starting your own projects when you write more or less anything. Even if you're not using anyone else's code, the zealots may well try to pressure you into adopting the GPL if you're using another license. Express to them an earnest desire that they cease to exist, say it loudly and adamantly, and repeat it as many times as is necessary for them to eventually listen and leave you in peace.
Re:Listen up: (Score:2, Informative)
Re:specifications! (Score:3, Informative)
I usually get small portions of it working during steps 1) and 2). These portions are very helpful to my understanding and development of a technical spec, and sometimes even end up as working code in the finished product. They may even be enough to get somebody else interested. But they are not enough to show an idea of the whole project to somebody who isn't reading the specs and the code thoroughly.
Re:First: work on an existing OSS project. (Score:3, Informative)
However, here is my advice on politics: every organization has politics and open source projects are no exception. Rather than work on eliminating problems, look at using them while mitigating harm:
1) Don't push people to contribute, but be grateful for any worthy assistance. Note the use of the word worthy. Make sure the quality is good before you give commit priv.
2) Understand that whatever structure you decide on having, there will be elements of benevolant dictatorship and community decision making. LedgerSMB is organizationally very community-oriented, but sometimes I feel like I am looked to as a constitutional monarch (not my choice, but I am the only one with a lot of experience in the insanity that is the current codebase). I have noticed the same trends in PostgreSQL and other more mature projects-- just because one is structurally democratic does not mean that someone does not rise to be the leader.
3) Work on getting support from every other related open source project. Some people may contribute toward your code, others may want to collaborate.
If you would like to continue this discussion, you can email me at chris.travers@gmail.com