Slashdot Mirror
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!
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!
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.
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.
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?
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
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.
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
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
...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.
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.
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.