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?"
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.
Write some code (Score:3, Interesting)
Cheers,
Jeremy
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: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:Write the App first, then distribute (Score:1, Interesting)
Re:specifications! (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 audience as early as possible. Don't get bogged down on it, but make sure you have a clear idea of how your release is going to look: again don't waste time, but take a bit of effort to make help files and readmes, otherwise your project won't take off no matter how good the code is. This is especially true for complex projects where some user training is required.
This flies in the face of traditional software development, but remember that in 99% of OSS projects there is no deadline and no budget. You don't need to get it right the first time, you need to keep people interested *while* you're doing it. It's important to make your code feel solid to the end user - it's not acceptable to release for Windows in a ZIP file unless your project is exceedingly small and simple. Make an installer: you need to display the GPL somewhere anyway.
That's my 2c as someone who has invested over three years in a project that gets plenty of downloads, but still no feedback or 'community' as someone else mentioned. What will drive your downloads is making sure there is always a new release available - most people check maybe once a month *tops*.
HTH