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

Listen up:

[Anonymous Coward]

No one cares about your LAMP powered digital picture archiving system.

Re:

[aybiss]

Sourceforge has the correct advice: Release Early, Release Often. I still get no feedback but I'm getting plenty of downloads.

Re:

[Anonymous Coward]

Sourceforge has the correct advice: Release Early, Release Often.

Which explains why Slashdotters don't have girlfriends.

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.

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

Re:Write the App first, then distribute

[laffer1]

Consider that someone has to be interested in your idea to contribute.

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:

[Anonymous Coward]

Actually both Debian and KDE were started as large ambitious projects with little more than a Usenet post filled with ideas. This approach is also good, but you'll still need to write everything yourself. The big announcement will just get you people to check up on your progress and keep you motivated to continue. At least until a few releases then you'll have users. And once it's really useful you might start getting patches or another full time developer.

Re:

[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 ch

Re:

[Short Circuit]

I should add that there is nothing more embarrassing to a hopeful OSS beginner than to have a history of incomplete projects behind him. It's much better to be able to show one or two completed projects than fifteen or twenty false starts. Sure, you can have all sorts of ideas...but can you follow through?

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

Re: your sig

[Sparr0]

Too many posts hit +4 *for you*. Some of us have slash configured to make Funny -3 instead of +1. Really helps with avoiding clutter when browsing at +3.

Re:

[oyenstikker]

I didn't realize you could do that. Thanks for the tip.

Re:

[Sparr0]

If you're curious, here are the settings I use, I find they make for a much more enjoyable slashdot experience. I marked the ones I remember changing with asterisks, but I might be wrong. Also, with my heavy friend/etc scoring it helps to have a larger friend network.

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

[Threni]

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

Re:

[toleraen]

So tell me, what's the difference between some anonymous person with a randomly generated user name, and some anonymous person that that didn't feel like adding even more user names to the /. database? Aren't they both anonymous (to you) in the end? How is the content of their post any less relevant? If it's junk (gnaa style), it's going to get moderated down anyway.

Besides, some of us actually use one common, original, uniquely identifying pseudonym for everything. It wouldn't be particularly difficul

Re:

[Threni]

> So tell me, what's the difference between some anonymous person with a randomly generated user name, and some anonymous person
> that that didn't feel like adding even more user names to the /. database? Aren't they both anonymous (to you) in the end? How
> 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:

[toleraen]

...if I see Elton John's name, I know what to expect...That's why I use a different nickname on every site I participate in.

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:

[Threni]

> Using a different nickname on each site is no different than posting as AC. You're not putting any
> 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:

[ComaVN]

moderate parent up!

Re:

[ak3ldama]

hrm, based on "release early and release often" how about this:

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!

[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.

Re:

[Ricin]

Amen

Re:

[oyenstikker]

I don't know anything about the SE textbooks, I never read any of them. I just know from experience that if I don't have some sort of specification, be it a polished document or just ideas in my head that I thought long and hard about, I'm going to produce some nice looking code that doesn't do anything useful.

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:

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

[oyenstikker]

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

Re:

[ScrewMaster]

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

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:

[aybiss]

14) Wish you'd skipped steps 1-9 because you're writing OSS, not an OS.

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:

[oyenstikker]

And 99% of OSS projects suck. I know it is very trendy to start writing code and worry about figuring out what it is supposed to do later and to spend a lot of time rewriting code written without a clear vision, but there is no substitute for proper planning. It is along the same lines of the old adage "An ounce of prevention is worth a pound of cure."

Re:

[aybiss]

Sorry, I was talking about the 1% of open source projects whose creators can actually code.

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:

[oyenstikker]

What do you mean by "see everything as a conceptual system"?

Re:

[aybiss]

I mean have the ability to break a goal into subprojects, and to analyse a need in terms of what a computer can and can't do. I'm saying that if you aren't the sort of person that can easily conceptualise a small project and think about it as a system you probably aren't going to succeed anyway. That being the case, documenting what you're doing is only wasting your own time and making you go over old ideas.

Only a very seasoned developer could hope to completely nail a more complex system the first time aro

Re:

[oyenstikker]

Regarding your example in your last paragraph - you didn't go through a ten step process, but you did design and write some sort of technical specification (on paper), and then revise that specification after seeing shortcomings. (There may be some people who can imagine a complete system and come up with the right design the first time around, but I am surely not one of them, nor do I imagine most people are.)

Why would that have been disastrous in a commercial situation?

Re:

[aybiss]

OK, this is definitely my last post on this subject. :-)

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:

[try_anything]

The missing step 12:

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

[Goose42]

1) Open development environment of your choice
2) ???
3) Profit!

Re:

[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 lov

Re:

[TheRaven64]

I think I'd regard c is more successful. I write Free Software because I want to run the resulting program. If someone wants to take over development effort then that's absolutely fine by me...

Re:

[cortana]

b, c and d are all successful. a is also not that bad--at least the code is out there for others to use, and the whole thing may be picked up by someone else later on.

A good question for once!

[Anonymous Coward]

Wow, an "Ask Slashdot" question that is actually appropriate for the Slashdot community!

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:

[Anonymous Coward]

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!

Re:

[hummassa]

No, just Perens. He already has eloquence that surpasses RMS and nobody really likes ego-driven people. ;-) [Respectfully, ok, Mr. Raymond??]

Re:

[markov_chain]

About the women part, here's how Eric Raymond works the ladies:

ESR busting a move [stonehenge.com]

Forgot

[markov_chain]

Here is the happy ending:

ESR kissing [spinster.org]

Re:

[krbvroc1]

Here is the happy ending:

ESR kissing [spinster.org]

Dude, I hate to break it to you and Bruce. I can ASSURE you that if you went to a 'reputable' massage parlor, that is NOT the 'Happy Ending'. I would ask for your money back.

Re:

[Bruce Perens]

Oh yeah, that GPL stuff never fails. It was a warm, sunny morning in California recently, when Valerie whispered in my ear: Tell me about derivative works, honey! And it just went from there...

A Few Tips

[mysqlrocks]

Start by reading Producing Open Source Software [producingoss.com]. Setup Trac [edgewall.org] or use Google Code Project Hosting [google.com]. Make sure it's something you're really interested in doing and committed to spending a lot of time on it. Other people probably won't volunteer their time if they don't see at least one other person strongly committed to the project.

Re:A Few Tips

[Secret Rabbit]

The problem with Producing OSS is that it is really biased, sometimes subtle, sometimes not so much.

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

[turbidostato]

"Start by reading Producing Open Source Software."

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

[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.

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.

Re:

[turbidostato]

"Document as well"

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:

[ABasketOfPups]

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:

[turbidostato]

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

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:

[Boronx]

Man: What do I need to do to become a writer?

Tolstoy: Write.

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:

[4D6963]

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:

[einhverfr]

I am involved in a couple of open source projects (see my sig). My most recent one, LedgerSMB, was a fork from another program and one we are working *hard* to get into shape (please don't hold the existing source code against us!).

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.

[ChaseTec]

Open source project aren't magically some field of dreams. Just because you build it doesn't mean they'll come. Either users or contributors. However if you do make something usable you have to guess by your download log that people are using your software, they won't bother telling you all the time, if you'r lucky 1-5% of your users will email you or post to your blog/forums/mailing list. Use a version control system, make user and developer docs and keep them up to date. You might want to just create a pr

Re:

[Ricin]

That is so true. Questions to special interest MLs or forums will generally remain unanswered, as they're typically not interested in projects that merely use some of their stuff in a secondary manner.

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

[Bluesman]

So you have an idea, that's the first step.

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

[Scarblac]

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?

[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.

Prototype

[ls -la]

I haven't personally done this, but it seems to me the logical thing to do should be work on it by yourself, or maybe with a friend or two if they're interested until you have a working sample, prototype or alpha test quality, and then set the project up on google code or sourceforge.

You really need to do as much as possible...

[CaptainPatent]

by yourself in the beginning. I have learned that people generally are not at all interested in an idea when it is just an idea, but when they see something start to come together it can pick up steam. Document like crazy first. Get your idea on paper and even code a lot of the base classes you need. Break down the work to be done into smaller projects. If you have a website for the project let people what functions or classes need to be written, if you don't have a website, get one! It will be invaluable t

Write some code

[JeremyR]

While ideas are great, having a working implementation of something is probably more likely to draw interest. It will also help you demonstrate to yourself that you're actually serious about committing time to your project.

Cheers,
Jeremy

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

How to start an open source project

[Anonymous Coward]

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.

Re:

[Ricin]

Mods! This is at least worth a +1 Funny.

Open source, closed source, starts the same way...

[argent]

You start a software project by writing software. Oh, maybe not at once, or maybe you write a prototype first, but until there's software... it's pointless to talk about how it's going to be licensed.

Build a first stable release with 80%+ features

[Qbertino]

Build a first stable version with 80%+ features intended. Then you can release it as open source. Don't start earlyer. When you release, do count on doing 20% project, website and community management at least. And count in a week or so to get accustomed to sourceforge.

A few thoughts

[psykocrime]

1. Write code

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

#> ./configure; ./make clean; ./make install

or whatever. The worst thing to do is provi

Website and Info

[Programit]

I've been designing and tinkering with a project for 18 months now on my own and have found it hard to get genuine help at times. What I plan to do myself, is setup a small website with my current code, design notes, a small message section etc. Include screenshots, and design graphics and a list of potential features AND then put the word out through various sites looking for help. People want to see the basics work before they help so you need to work on at least a basic dmeo code of your project then se

Re:

[Ricin]

Have a working release. Package it for one or more distros. Don't count on people to join or help you. It's great if they do, but my experience has been that if any, my feedback consists of the odd bug report (which I may or may not be aware of) and few people who actually want to try experimental code that I've hacked up for them.

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:

[jaavaaguru]

I'mfollowing close behind you - I've been doing some designing and tinkering for around 5 months now and have only just released the source code on the Internet. I had the website there a couple of months before the code was ready to put online. I've got some demos of what my project can do, and people can now download binaries and source. I'm thinking of what to do next... it may involve a Wiki or moving the source to somewhere more central like Sourceforge (as I already have an account there).

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:

[logixoul]

Quite funny & on track. I didn't get the foundation bit though. Why does anyone want you to set up one?

Despite what you may have heard...

[petrus4]

...I strongly advocate starting your own project from scratch, rather than going anywhere near pre-existing code to the degree that you can help it. Do not listen to the brainless lemmings who screech and whine about "duplication of effort." If it's *your* effort that we're talking about, you have every right to tell them to leave you alone.

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

[epee1221]

I started from scratch because the problem I wanted solved wasn't all that common, and I didn't expect there to be much existing open-source code. Turns out that there's a lot that solves a similar problem, or covers a subset of the functions, but that it would probably be easier to start from scratch than to expand/generalize the existing code.

Re:

[StrawberryFrog]

3) Often earlier implementations of a particular idea will be written in a technically inferior, less stable, less secure way.

On the other hand, so many people starting afresh end up reinvent the wheel. And doing it badly.

Re:

[KMonk]

Not sure if the poster is talking about trying to code all the functionality from scratch, no libraries. If so, this is an absolutely awful idea for any but the smallest, most trivial projects. If you try to code your own, say, ORM solution you are duplicating the effort of hundreds of smart people over long periods of time. You'll never get a chance to do your actual project. If you are using GPL stuff, you are restricted to leave your stuff open. What a great opportunity to write something useful somebody

Re:

[petrus4]

You're exactly the kind of person who I was talking about in 4). I'm not surprised you were unable to consciously identify yourself as such. Fear-based zealotry and self-awareness rarely go hand in hand.

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.

I can provide free hosting and some support

[wikinerd]

If your project captures my interest, I can provide you free web hosting and other supporting infrastructure (eg a CVS or SVN server).