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?"
No one cares about your LAMP powered digital picture archiving system.
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.
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!!!
The masses are the crack whores of religion.
1) Open development environment of your choice
2) ???
3) Profit!
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 isn't one of them - good luck!)
Seriously, this isn't your job. No PowerPoint -- just do it.
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!
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.
Start by reading Producing Open Source Software. Setup Trac or use Google Code Project Hosting. 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.
Bradley Holt
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.
I believe posters are recognized by their sig. So I made one.
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...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
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 project on sf.net. If you want others to contribute eventually make sure the tools and libraries you choose are common ones. Mailing lists or forums are nice but don't worry about them until you've got something kind of stable and have time to devote to managing your community. And for the love of god, COMMENT YOUR CODE!
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I didn't realize you could do that. Thanks for the tip.
The masses are the crack whores of religion.
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 with it. Provide updates and communicate new ideas before implementing them. Most times, someone else will suggest something else that will lead you in a different direction than originally planned, and often this just makes you more productive.
Count on doing almost all of the work by yourself, because with the thousands of active, interesting projects, you'll be lucky to get a lot of help. Nobody will be as attached or dedicated to your idea as you are.
But most importantly, it has to be useful and/or show a lot of promise before you do your first release, otherwise people will try it and get a bad impression.
If moderation could change anything, it would be illegal.
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.
I believe posters are recognized by their sig. So I made one.
Because lord knows we need more frameworks.
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 you just hate it when people reply to your signature?
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.
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 to help describe the goal of the project, the desired result and what is currently needed. It will take a long while to get the ball rolling on any large-scale project and it will be very difficult to get enough interest. All you can do is start and hope others will follow.
Well, back to rejecting software patent applications.
1: Make sure you have the talent, motivation and time needed. Every OSS project needs a good leader.
2: Write a roadmap and design-document. Nothing fancy, just describe what you want so that everyone in the team knows where the project is going.
3: Advertise and get developers to join the team. But keep in mind that you will need to do most of the work yourself.
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
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.
I am TheRaven on Soylent News
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 I browse with a threshold of 3*.
Hmm, good question, standard OSS practice seems to be the following:
1. Create project on sourceforge
2. slap together some steaming mounds of code
3. release project on sourceforge
4. ignore any bugs, promptly call project a success
these are the flaws of most open-source projects, people don't see if there is an existing codebase that they can leverage off. Everyone needs to re-invent the wheel. My linked list is better than X's linked list.
Don't bother to give any documentation other than a simple readme, or how to compile the source, especially NEVER include any testcase, we can create our own.
Don't ever comment your code either, it was hard to program that bubblesort algorithm project, it should be hard for other people to understand too.
Make sure you use obsure variable names, don't follow any standards either.
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 believe that such people are incapable of coming up with a nickname.
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
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.
Real Men turn all this shit off and browse at -1 with no score display. Only sheep require a numerical indication of a bunch of other peoples' opinions about something in order to appreciate it.
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.
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 difficult to identify who I am in RL. There are times when there is certain information I want to post, but I don't want it associated with me. What's the point in bothering to log off, log in as a different user, post, log off, and log back in? A simple check of the "Post Anon" box works much easier.
> So tell me, what's the difference between some anonymous person with a randomly generated user name, and some anonymous person /. database? Aren't they both anonymous (to you) in the end? How
> 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 Elton John's name, I know what to expect, and it's not pretty. If he - and millions of other people - all released albums under the name Anonymous, I'd not know what to expect, and if a lot of them were really shit then I'd not be interested in checking any of them out. If you get an account here, and use a nickname, I can permanently mod them down by making them a foe (yeah, I forgot to mention that I -5 foes too).
> Besides, some of us actually use one common, original, uniquely identifying pseudonym for everything. It wouldn't be
> particularly difficult to identify who I am in RL.
That's why I use a different nickname on every site I participate in.
> There are times when there is certain information I want to post, but I don't
> want it associated with me. What's the point in bothering to log off, log in as a different user, post, log off, and log back
> in? A simple check of the "Post Anon" box works much easier.
The point would be that if you do that, I'll read it. If you post as anon, I won't. I'm not sure that'll negatively affect your quality of life in any appreciable manner, but I don't have time to read every single post on Slashdot, and I find that avoiding all the losers that post utter nonsense anonymously saves me some time.
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.
We suffer more in our imagination than in reality. - Seneca
Here is the happy ending:
ESR kissing
Tsunami -- You can't bring a good wave down!
1. Write code
./configure; ./make clean; ./make install
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 provide a tarball that won't build, or that requires all sorts of extra work
to setup the build environment, or telling people "just grab HEAD from CVS" when you know HEAD is broken 90% of the time.
// TODO: Insert Cool Sig
...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.
...I don't have time to read every single post on Slashdot...
/. moderator that I am...). When I come across the inevitable troll thread, I just minimize the thread and move on. Quick, easy, and seemingly more informative.
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 behind your name at all, so what's the point?
Being logged in as Toleraen to every site I participate in would be like releasing albums, dvds, tour tickets, t-shirts, etc as Toleraen. If I wanted to go to a movie, maybe I'd put on a hat and some glasses and go incognito, aka, AC.
The point would be that if you do that, I'll read it.
I really don't care if you read what I write. I just never understood the "All ACs are 'losers that post utter nonsense'" argument. I've never seen it explained by anything other than broad generalizations about all ACs. Plenty of AC posts have good information in them.
So why don't you just read at +3, leaving ACs at their normal default? I've posted plenty of posts as AC that get moderated to +5. Those posts were obviously insightful, and not 'utter nonsense'. You're skipping past good, relevant information in doing that. If you just want to get to the good stuff, it seems like keeping the good AC posts visible would be the common sense thing to do.
I'm not trying to troll or pick a fight, I just plain don't understand that line of thinking. Then again I read at -1 (being the good little
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 seek further help. Part of a team development is you need to have an area where collaboration between all members, and potential members, can be seen. Discussions, ideas, demos, code snippets etc. (Wikis are good for this such as Tiki Wiki etc.)
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
darcs init
(blah blah blah blah lame)
...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 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.
"The use-mention distinction" is not "enforced here."
XHTML version
postscript version
docbook xml version
all of those found here
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.
moderate parent up!
Be wary of any facts that confirm your opinion.
> Using a different nickname on each site is no different than posting as AC. You're not putting any
/. moderator that I am...). When I come across the
> 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, someone should be filtered away because I disagree with comments they've made on a forum about fishkeeping. What would be the point of that?
> Being logged in as Toleraen to every site I participate in would be like releasing albums, dvds, tour
> tickets, t-shirts, etc as Toleraen. If I wanted to go to a movie, maybe I'd put on a hat and some
> glasses and go incognito, aka, AC.
So I should stop reading Iain Banks books just because Iain M. Banks sci-fi books suck? There are many other examples of people using multiple names to get work published.
> Those posts were obviously insightful, and not 'utter nonsense'. You're skipping past good,
> relevant information in doing that.
I'm not saying that all comments posted as AC are nonsense - just that I need some sort of filter here, as clearly I'm not going to read every comment on every story.
> I'm not trying to troll or pick a fight, I just plain don't understand that line of thinking. Then
> again I read at -1 (being the good little
> inevitable troll thread, I just minimize the thread and move on. Quick, easy, and seemingly more
> informative.
I moderate sometimes, and I'll surf at -1 then. But I ignore trolls as someone else will moderate them down. I try and moderate up interesting stuff, as per the instructions here.
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.
If your project captures my interest, I can provide you free web hosting and other supporting infrastructure (eg a CVS or SVN server).
Read _Producing Open Source Software_ by Karl Fogel. You can read it online at http://producingoss.com/.
He's got lots of good advice, and it's from somebody who knows.
-AC