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?"
Listen up: (Score:3, Funny)
Re: (Score:2, Informative)
Re: (Score:2, Funny)
Which explains why Slashdotters don't have girlfriends.
Write the App first, then distribute (Score:5, Insightful)
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 (Score:5, Insightful)
I've released/maintain three different open source applications/frameworks; Tcl PIC [sourceforge.net], UPS Print Plugin [sourceforge.net], and WyattERP [sourceforge.net]. 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 :)
Re:Write the App first, then distribute (Score:5, Interesting)
I work on three open source projects and am the founder of two of them. All three projects suffer from limited number of committers. In fact, I am the only committer for Just Journal. Granted, the code sucks balls and I didn't expect to open source it when I started. Don't assume that people will use your code or contribute back. If you get lucky, you might have the next big thing.
Even when you actually have other developers, sometimes people think you are too small to matter. MidnightBSD, for instance, has 5 active developers and a few people working on translations and things. For an operating system project, that is quite small. DragonFly started with around 8 developers early on as far as I know. However, most people think I'm the only developer since I commit the most. Perceptions are the big problem.
The idea that you need to release first is correct. Many people email me with comments like "I'll join the project after you release a version" and "I don't want to try this until you get a few releases out". Well I could do a release right now that sucks. Sadly, that would work with some people.
You may also find that the demands of users are unbelievable. The requirements for the first release have changed several times. Intially, it was to be a non gui release with just some basic changes to get familar with the release process and to offer a stable starting point. I decided waiting a few years to do a 1.0 release like DragonFly isn't the best idea for our situation. Now people expect a full working desktop environment for a 0.1 release. It amazes me.
I suppose the reaction you will get will vary greatly on the type of software you are developing and the license that you choose. GPL fans are supportive of GPL'd code IF it runs on Linux. If you GPL something for another system, its often problematic. If you even try to port software to another OS, you often get comments about it not being linux or how you should give up or the classic "BSD is dying". Now if its a killer application or product that is missing, you might get lucky. Imagine a world without Firefox or Pidgin.
Also don't make the mistake I did and be accepting of different licensing models. My project uses BSD, LGPL, GPL and several other pieces of code and everyone hates me. How dare I use GNUstep in my BSD project from people who use DesktopBSD (KDE isn't BSD guys). It is really interesting to interact with different projects though. There are projects that I didn't think much of until I submitted patches. For instance, I had a great experience with the Perl project. They are very nice developers. The GNUstep people have been very helpful too. So also consider who you might alienate. FreeBSD fans want me to die for forking.
Re: (Score:1, Interesting)
Re: (Score:2, Insightful)
My Citygen and Rosetta Code projects were created before they were released, and have fared much better than, say Apparition (a program I envisioned which was intended to be an efficient replacement to Symantec Ghost). Another project I worked on last summer, a PHP character sheet for the d20 system, got out a few betas, but I ultimately ran out of time to work on it.
(For the record, Citygen is GPL, Rosetta Code is GNU FDL, and the d20 ch
Re: (Score:1)
specifications! (Score:5, Insightful)
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!!!
Re: your sig (Score:1, Offtopic)
Re: (Score:2)
Re: (Score:1, Offtopic)
+1 Insightful
+1 Interesting
-3 Funny*
+1 Informative
-1 Offtopic
0 Flamebait*
-1 Troll
-1 Redundant
+3 Friend*
+1 Fan*
-3 Foe*
-1 Freak*
+1 Friends of Friends*
-1 Foes of Friends*
0 Anonymous
+2 Karma*
0 Subscriber
-1 1% New Users
And
Re: (Score:2, Funny)
Re: (Score:2)
Besides, some of us actually use one common, original, uniquely identifying pseudonym for everything. It wouldn't be particularly difficul
Re: (Score:1)
> that that didn't feel like adding even more user names to the
> is the content of their post any less relevant? If it's junk (gnaa style), it's going to get moderated down anyway.
It's not that they're anonymous. Elton John's real name is Dwight York or something. I don't really care what it is - if I see El
Re: (Score:2)
Elton John uses the same name on everything. Albums, on tour, DVDs, T-Shirts, etc. If he used a separate nickname for everything else he does, like you do, he'd use Elton John for Albums, Frank Timber while on tour, Jack Barnson for DVDs, Peter McDoodle on t-shirts, etc. Using a different nickname on each site is no different than posting as AC. You're not putting any reputation b
Re: (Score:1)
> reputation behind your name at all, so what's the point?
Using a different nickname on each site is completely different to posting as an AC. I don't care what you do on other sites. I have - and will - never check to see what someone with a given nickname on Slashdot is doing elsewhere...I just don't care. To do so would be to suggest that despite posting only sensible, thoughtful comments here, so
Re: (Score:2, Funny)
Re: (Score:1)
1. ) Partially complete useage case specification.
2. ) Setup Wiki and mailing list.
3. ) Write some code.
4. ) Release Alpha.
5. ) Rinse and Repeat and hope a community forms.
Re:specifications! (Score:5, Insightful)
4) Prototype
10) Start implementation. Get portions of it working
the first ones. I know what the SE textbooks say, but you have to get started, especially if it's your own personal project and you're looking to get people involved.
You must start, it's critical. Do not create a Sourceforge account. Do not create a Google Code account. Do not create or commission a website. Do not apply for an SVN account from the admins. Do not create icons. Do not gather a mountain of docs and resources. Do not attempt to specify your specifications. Do not test different IDEs, frameworks, GUIs or databases. Do not read blogs - no 'planet' blogs, no developer blogs. Do not, under any circumstance, create or commission your own blog. Do not pass Go and do not collect $200 until you have got the bloody thing going.
Re: (Score:2)
Re: (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
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
In other words, "look before you leap."
Truly, a little planning does go a long way. There's no excuse for someone that is working on a project by himself, with no deadlines, no boss looking over his shoulder grumbling "aren't you coding yet?", to skip writing at least a preliminary specification. Oh sure, we all hack quick-and-dirty solutions now and then (sometimes it can be fun just to crank someth
Re: (Score:2, Interesting)
Seriously, speccing and coming up with working releases is NOT a requirement for starting an OSS project, and IMO it's not even advisable. Of course it is important to have a clear idea where you're going and whether you can realistically get there, but not like in a commercial environment where missing the goal or taking too long is as bad as doing nothing at all.
Get into the swing of packaging your releases and interfacing with your au
Re: (Score:2)
Re: (Score:1)
If you don't see everything as a conceptual system from the start, you aren't the sort of person who is going to take an idea and turn it into a computer program anyway.
Re: (Score:2)
Re: (Score:1)
Only a very seasoned developer could hope to completely nail a more complex system the first time aro
Re: (Score:2)
Why would that have been disastrous in a commercial situation?
Re: (Score:1)
Firstly just one small thing, my revisions were done as code. My technical docs are now a side project that attempts to keep up with what is implemented. The simple fact is that noone will be interested in these docs until there is a much larger number of people interested in the binary. The best source of technical information about my project right now is my source code, which I take pains to comment well.
I agree that not many people can imagine a co
Re: (Score:2)
Maintain a list of features users might expect, and whether your software supports them. Make this list a focal point of the project's web site.
Nothing sucks more than having to download, build, install, and use a program to see if feature X is present and functioning. Most people won't even bother. If you're releasing a dev tool for C++, make a checklist of C++ language features and document which ones your tool supports. Don't make someone run it on their data and see a bunch of er
Simple steps (Score:3, Funny)
2) ???
3) Profit!
Re: (Score:2, Insightful)
2) ???
3) See one of the following:
a) Abandon project, no one is interested (see at least 50% of source forge)
b) Idea is good, people like it, but you're implementation is lacking, code forks.
c) People love it, everyone is using it and working on it, but you don't have time to work on it
anymore so someone else takes over.
d) People lov
Re: (Score:2)
Re: (Score:2)
A good question for once! (Score:1)
I'm getting so used to dumb questions asking complete strangers about legal/career/personal advice (which the slashdot community is completely unqualified to answer) that I had begun to believe that there wasn't any point to Ask Slashdot other than to read "expert" advice from teenagers who think they should know anything.
Luckily your question should actually get some useful answers from people here! (Admittedly, this is
Here are several things you need to do: (Score:4, Funny)
Good luck and happy coding!
Re: (Score:1)
Re: (Score:2)
ESR busting a move [stonehenge.com]
Forgot (Score:1)
ESR kissing [spinster.org]
Re: (Score:2)
ESR kissing [spinster.org]
Re: (Score:3, Funny)
A Few Tips (Score:5, Informative)
Re:A Few Tips (Score:5, Interesting)
For hosting sites, I'd like to add http://www.berlios.de/ [berlios.de]. Especially since they're outside the US and as such not subject to the US's insane laws (read: things like the DMCA).
As another recommendation, you have to have something before you ask people to join. And that does NOT mean just some code. You're going to have to have a good amount of documentation so developers will know: what you're doing, what direction you're taking, there ass from a hole in the ground when it comes to your code, etc.
Also, don't be too liberal with who you give commit access to. If you're too loose, then someone coming along could really screw you. Or not contribute at all and just lie about it b/c they have commit access. Or people could complain that Larry got commit access straight away, why do they have to work for it so hard. Among other problems.
I imagine that you have a couple buddies that might be interested in helping out. I'd recommend asking them first, design, document, get a hosting account somewhere and then develop. After something is produced, then start looking for extra help.
You're also going to have to consider how the project is run. Will it be a purely community based one, a benevolent dictatorship, or somewhere in-between? Stuff like that is going to have to be spelled out. Otherwise, you're going to run into problems with people thinking that they have "power" beyond what they actually have or not thinking that they have "power" that they actually do. Either way, that's never good for a project.
At any rate, that's my 2 cents.
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.
Just code (Score:5, Insightful)
A new project is not an open source project yet - it's just a project you work on. So just start developing it, just like you would a "closed source project".
Now say you are successful, you manage to create something interesting. Once you have it working, in a state so that other people may be interested in using it, then you could release it. And then, if you happen to pick an open source license for it, it'll be an open source project. But not before.
Sourceforge is full of projects that started out trying to be an "open source project" from the start, but never had any actual code... don't delude yourself.
Don't JUST code (Score:5, Insightful)
The other important thing is not to get too attached to your code. Code with the attitude 'this sucks, but it will do for now,' and then you won't be too resistant to other people improving your code. One of the hardest things about Open Source development is that other people will be touching your code. It's very easy to get possessive about your code and be upset by other people hacking at it (I've been guilty of this a few times). If you founded the project, then you have final say over what goes into your tree, but if you piss off enough competent developers then you will find your project forked and yourself forgotten.
Re: (Score:2)
How can this be insigthful? TheRaven64 starts from the implicit assumption than one thing is coding and a different once is documenting. The "code" is both computer understandable sentences *and* human explanatory sentences (aka documentation). *That* is insightful.
The fact that you feel you need to say "don't only code, but document too" because you see it as two different things is the root of all evils on IT.
Re: (Score:1)
The fact that you feel the need to say documentation and code are not two different things is ALSO one of the roots of all evils in IT. While comments like "a = a + 1 # increment a" are less than useless, a document that says "here's what the code is meant to do, it uses the following algorithms to do it, we tried these others but had problems X and Y, and the database tables it uses are A, B, and C" makes life considerably easier. Especially for the folks who come next. For the folks who end up looking a
Re: (Score:2)
But I don't "feel" the need to say it. I *see* the need, since somebody else said otherwise. Just like you don't feel the need to tell everybody that 2+2=4, since that's obvious... unless, of course, someone says it's 5.
"While comments like "a = a + 1 # increment a" are less than useless, a document that says..."
That's why I talked about documentation, not code commentin
Re: (Score:2)
Tolstoy: Write.
The problem isn't starting... its finishing... (Score:5, Insightful)
If you don't know how to code, or can't get what you want done with your knowledge, you are in a heap of hurt. Cause your job now becomes finding a good developer willing to code your project, has the time to do so, and you have to motivate him/her to work on it. Once you get to the point where you can release the code, publicize it as best you can, and if you get a small following, you have support for years.
But, 9 times out of 10, it'll fall flat on its face and fail somewhere in the middle. I'm not trying to discourage you, but you HAVE to have the motivation from start to finish, or it will fail...
First: work on an existing OSS project. (Score:5, Insightful)
First: work on an existing OSS project. (Next, do it again.)
Second: after you've learned what you like and don't like about the experience, you'll know a little about what you want to emphasize and what you want to avoid in your own project.
Long story short, leadership in any area takes some practice, but it's easier to get started if you find a mentor or two along the way that have behavior, methods and attitude you can copy.
Re: (Score:2)
First: work on an existing OSS project. (Next, do it again.)
I disagree. I think it's much easier and interesting to start your own project, all alone, and eventually, once you need it, let/make/beg people to join your project. I think an OSS is a hell of a lot more about developership than leadership, when you start you won't have anyone to lead anyways.
Re: (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.
Understand that no one will help you. (Score:2)
Re: (Score:2)
Also, feedback will generally be sparce and lousy. Try to get the most out of the few users who do contact you. If they're merely annoying or beating a dead horse, ignore them. Little feedback may simply mean that the people who are using your software have no or few problems with it.
I only put my project up o
Easy (Score:2)
Now, develop your idea by yourself until it's something useful, that other people might be interested in using.
After it's working, meaning that it doesn't crash, has most of the features, and is actually useful, post the code and documentation on Sourceforge (www.sourceforge.net).
From that point, you can use the various tools Sourceforge provides to manage your project and get feedback from users.
Pick one form of communication that developers will use, and stick wi
RentACoder (Score:5, Interesting)
I'll just throw an idea out here: there are sites, like RentACoder, where people who need software built can post a bid request, people can bid on them, and collect the fee once the project is completed. Professional western programmers typically don't bid on serious projects, since typical fees are ridiculously low for the work (even for less developed countries).
However, that does mean that if you have a random idea but can't get around to starting work on it, you could perhaps put it as a bid request on there. You might be out say a couple hundred dollars (depending on what you want built), and the code might not be the best quality, but it'll at least work somewhat or you won't have to pay.
And then you can start improving it, refactoring it, whatever you wish... and perhaps release it as open source.
Just an idea - using a site like that to get over your own fear of starting / lack of time or experience.
Has anyone else implemented your particular idea? (Score:5, Insightful)
Prototype (Score:1)
You really need to do as much as possible... (Score:1)
Write some code (Score:3, Interesting)
Cheers,
Jeremy
Start simple (Score:5, Insightful)
As the author of a couple popular open source programs, my advice is to start simple:
1) Write a working prototype. It won't have all of the features on your wish list, but it had better compile and run. You should have plenty of clear comments in the code too since you're expecting other eyes to see it.
2) Add the legalese for the license of your choice. The Gnu Public License is popular, but lately I've been using the BSD license. Definitely go with one of the available licenses rather than writing your own.
3) Make a Web page for your project. Include a description, example, screenshots, binaries (optional), and of course the code.
4) Announce the availability of your code. I used Freshmeat in the past. Paying a few tens of dollars a month for Google Adsense advertising might help get attention too.
That's all you need to start. If the project is good then you will attract users, some of whom will contribute bug reports, suggestions, or code. Grow from there.
AlpineR
How to start an open source project (Score:5, Funny)
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.
Re: (Score:2)
Open source, closed source, starts the same way... (Score:2)
Build a first stable release with 80%+ features (Score:3, Informative)
A few thoughts (Score:2)
2. Write code that does something useful
3. Make the code easy to download and easy to build.
4. See step 3
5. See step 4
All joking aside, that is a huge hurdle that many projects don't get past. If you want people to contribute, they *MUST*
be able to build your code. Preferably by downloading a tarball, extracting it and just typing one command, whether it's
#> build.sh
or
#> ant clean package deploy
or
#>
or whatever. The worst thing to do is provi
Website and Info (Score:1)
Re: (Score:2)
I don't think you should assume any bigger than what feedback suggests. And remember that few feedback may also mean that it works fine for most people who try it.
I know that my p
Re: (Score:2)
Hire a bunch of people to do it for you (Score:5, Insightful)
Just to keep from getting flamed here, I do own a business and do not maintain projects per se. I do maintain modules for various projects, including Drupal, Scoop, Plone and Joomla. I release everything under the GPL license and look at this as an active way of supporting communities that my business is based on.
That said, running a project is hard work. Going commando on it, i.e. building the whole damn thing yourself and making it all work, is a life altering experience. It always looks so glamorous when you start, but quickly comes to be a part of what you do each day. If you have a day job, it will become your night job. If you are a student, this will become your teacher. Remember that as you try to get to an initial release.
When you do release something, one of two things will happen: a) no one will notice or b) everyone will talk only about what it can't do. Either way, no one will appreciate what you have been doing.
If you decide to continue updating it, you will be faced with tough choices. You will have to decide about what features need to be included in the project, prioritize requests that come in, and figure out a realistic schedule that allows you to get things out the door. People who do follow your project will be clamoring for things and you will have to put up with people who make threats to fork your project unless you add something completely stupid and useless. Deciding who to listen to is an art, and you will suck at it at first because each project is different and nothing you have ever done will prepare you to accept criticism without any expectation of reward.
If you decide to go on from there, someone will eventually submit a patch. You will probably have no clue what it is about at first, and it will take a lot of going back and forth to establish a rapport with that individual to figure out what it is supposed to do. You will probably wonder why you never thought of doing things that way and be impressed by the person who submitted it. If you ask them to work on the project with you, you will find out they are a male supermodel or billionaire with no real interest in programming and only submitted it because it was so obvious.
If you decide to go on after receiving community comments and patches from users, congratulations! Someone will likely come along with a competing project, since everyone knows they can do a better job, and you will lose half your user base. Your ranking on sourceforge and freshmeat will drop dramatically and traffic on your mailing lists will all but halt.
If you decide to go on after the ice thaws, you will find that people think about what you do as old school or hardcore. Congratulations, you are now several years older and this thing has been the center of your life for a long time. Your close relations probably have developed negative attitudes towards the time you spend on the computer and you are going to spend time thinking about ways to get your life back on track.
If you decide to go on after your mid life crisis and the child custody hearings after your wife leaves, you will find people calling for you to set up a foundation. Congratulations, you now get to deal with more lawyers! They are always a fun bunch and you are going to enjoy getting to know all your long time supporters as you beg them for donations to afford the spine breaking legal fees.
If you get your papers in order and set up a means to support the project long term, you will find that you have officially made it in the world of open source. Congratulations, you get to deal with the outcomes! If the project was worthwhile, it will have been adopted by organizations worldwide and you will have made no money off of it. You may be lucky enough to get a job somewhere being paid to support the thing, but those are rare cases. If it was not useful, you will find yourself writing a note to your users telling them how fun it has been and how other commitments are taking you away for a while.
M
Re: (Score:1)
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.
I'll speak to number 3 (Score:1)
Re: (Score:2)
On the other hand, so many people starting afresh end up reinvent the wheel. And doing it badly.
Re: (Score:1)
Re: (Score:2)
The Cathedral and the Bazaar (Score:2, Insightful)
XHTML version [catb.org]
postscript version [catb.org]
docbook xml version [catb.org]
all of those found here [catb.org]
ESR bay have become an asshole or whatever the slashdot crowd thinks about him nowadays (I honestly don't know him so I couldn't really say), but CatB is still a good reading.
Developers = users (Score:3, Insightful)
So limit your scope for your first release, and get something working and usable ready first. Only once things are sort-of working for a first generation of users should you advertise it a bit: first impressions do count.
I can provide free hosting and some support (Score:2)