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?"

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.

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!!!

Just code

[Scarblac]

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.

Re:Simple steps

[orclevegam]

1) Open development environment of your choice
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 love it, everyone is using it and working on it, you successfully manage to keep it on
            task and moving forward. Congratulations, you have a successful open-source project.

The problem isn't starting... its finishing...

[FortKnox]

There are COUNTLESS open source projects that even make it to alpha. Open up a project at, say, sourceforge, and start coding. Don't worry about doing it the corporate way, as that really doesn't buy you anything unless you know what you are doing.
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.

[xxxJonBoyxxx]

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?"

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:Write the App first, then distribute

[fishybell]

Exactly,

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 :)

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.

Don't JUST code

[TheRaven64]

Document as well. Once you have an alpha release, if the project is interesting then you are likely to get other people wanting to get involved. Make sure you document your interfaces, and document the high-level design behind your code. This makes it a lot easier for other people to dive in and fix bugs (which is great, since you don't have to), or add features.

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.

Start simple

[AlpineR]

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

Re:specifications!

[phrasebook]

I would make these steps:

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.

Hire a bunch of people to do it for you

[techsoldaten]

I was recently facing the same dilemma. I saw a market need for a module for a specific open source application and realized, between proposals, managing people, hiring developers, etc., the best thing I could do is augment my existing staff and bring on people to actually write the code.

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:Write the App first, then distribute

[Short Circuit]

Seconded. Write the first version yourself, then release, then grow.

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 character sheet is GPL. I'm hoping to get Citygen moved over to Google Code, where d20cs already is, but I'd like to keep the Subversion history intact. I need to find out how to do that.)

I've got a couple other project ideas which I've mentioned in a few circles, and have even fleshed out the specs for, but I haven't tried to get anyone involved in their development. And I won't, until I have at least a basic version of the software up.

The Cathedral and the Bazaar

[kantier]

you could start by reading this interesting document.

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

[obi]

One major thing to remember is that in the open source world, developers are almost always users first. So if you don't have any users, you're going to have a really hard time attracting developers.

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.

Re:specifications!

[larien]

Some said Amen to just writing code, I'm saying Amen to this. You don't need a full functional spec, but spend some time (might just need 5 minutes) writing down what you want the app to do at a basic level, a few bullet points is probably all you really need. Some simple pointers like this will get you thinking about how to structure your code now so you can build on it rather than having a hotch-potch of code which barely does what you want and you daren't touch for fear of breaking it.

Re:specifications!

[oyenstikker]

In my experience, the people who say "Amen" to just writing code end up with lousy architecture design.