Challenges in Releasing Open Source Software? 24
Chris Vaughan asks: "Me and my Co-Workers at the Advanced Computing Research Lab are just about ready to release our first Open Source package on SourceForge.net I ask the Slashdot community what hurdles they had to overcome and how much involvement do they still have in their project years later. Also what types of licensing did you pick and why did it suit your project best? Our project, MyPBS is a PHP/MySQL/Perl frontend accounting package for the Portable Batch System (PBS). Which is used to account for super computing usage. I appreciate any comments you may have."
A few thoughts (Score:4, Informative)
License: Pick the one that best suits your project and how you expect people to use it (or not). Normally SF requires that you use one of the OSI approved licenses. [opensource.org]. For example, if your application is a library (doesn't seem to be) then you wouldn't want to use the GPL; OTOH the GPL is normally fine for standalone apps. If you're not sure, talk to a lawyer.
Other than that, in SourceForge the trick is to categorize your project in the Software Trove very carefully. Otherwise people will have trouble finding it. I've found stuff in Freshmeat through Google that I couldn't find browsing the trove because the developer miscategorized his/her work.
No one will use your stuff if they can't find it.
You need to review the MySQL licensing scheme (Score:5, Informative)
Apparently PostFix's OSI Approved IBM Public License does not qualify so I'm having to prep to pay for licensing since we use postfix with MySQL (confirmed with their licensing folks). They did assert that they were still in the process of reviewing other licenses.
Re:You need to review the MySQL licensing scheme (Score:3, Interesting)
According to the GPL, there are no restrictions on use. So why is MySQL making you buy a license?
Re:You need to review the MySQL licensing scheme (Score:3, Interesting)
covered by this License; they are outside its scope." Also note that 2b only specifies that the results need be under the GPL (thus necessitating GPL-compatible licenses) if you distribute it. Their view of whether making and using copies within an org
Glad you asked! (Score:5, Informative)
You picked a good time to ask -- I just spent the last few hours putting out a new alpha release of the jSyncManager (http://www.jsyncmanager.org [jsyncmanager.org]) up on our project site at SourceForge (http://sf.jsyncmanager.org [jsyncmanager.org]).
(The jSyncManager is a pure-Java data synchronization solution for PalmOS based handhelds that is completely platform-neutral, with an open API, easy extensibility, and its own jConduit plug-in architecture).
I started this project back in 1997, writing the jSerial API, and latest the jSyncManager itself. It saw its first release (free, but under a closed-source license) in May 1999. It's gone through several iterations (including an IBM released version called ManplatoSync for Java [ibm.com]), finally being released under an Open Source license in September 2002.
I not only work on it daily still, but I'm in the process of setting up a software service/integration/development company around it.
My biggest challenges include trying to involve other developers in the project -- we have a small core, and users do occassionally submit patches, but attracting Open Source developers that actually make any contributions can be a real hassle. If your experience turns out to be like mine, you'll have lots of good intentioned people offer to help out, but will have a very difficult time finding people who will actually do any work, or make contributions without prodding. It can take a while to find developers who are real gems (although when you do, you'll invariably find yourself making some good friends and contacts -- your core developers are your biggest asset).
Some suggestions:
As for licensing, I chose to release the API under the LGPL to allow developers to choose their own licensing for any plug-ins they develop that use the API, and the GPL for our applications and the core plug-ins that we've developed. In this way we can ensure that our applications and plug-ins can't be integrated into a closed-source project, and can't be modified and released as closed source by third parties, but they can develop closed-source applications that call our library (although any changes to the library sources must be released as Open Source). So far users appear to be very happy with this arrangement.
Brad BARCLAY
Lead Developer & Projet Administrator,
The jSyncManager Project [jsyncmanager.org].
No problems (Score:5, Insightful)
For the open-source projects I have, I simple made them available via freshmeat [freshmeat.net]. My CVS repository is on my own machine. I have the projects' home pages on a seperate web server machine. That's it.
As for remaining involved, I'm still involved almost exclusively. I know the romanticized "bazarr" model of development envisions lots of contributors. The reality is that most open-source projects just get downloaded. Rarely do they accumulate talented people who make contributions. For all my projects combined, I've maybe gotten a handful of patches over the years (and most of those were pretty crappy quality, so I ended up rewriting them).
Hence, unless you expect your project to be wildly successful, don't expect much of anything, problems or otherwise.
Tip of the day (Score:2)
Make sure you have a mailing list to which all CVS checkins are logged, and subscribe to this. Then, be open with giving people CVS access if they are interested.
Otherwise lack of developers will kill the project once you grow tired of it.
Choosing a license (Score:2)
Grab.
Open Source Development HOWTO (Score:5, Funny)
1. Introduction
As everyone knows, Open Source software is the wave of the future. With the market share of GNU/Linux and *BSD increasing every day, interest in Open Source Software is at an all time high.
Developing software within the Open Source model benefits everyone. People can take your code, improve it and then release it back to the community. This cycle continues and leads to the creation of far more stable software than the 'Closed Source' shops can ever hope to create.
So you're itching to create that Doom 3 killer but don't know where to start? Read on!
2. First Steps
The most important thing that any Open Source project needs is a Sourceforge page. There are tens of thousands of successful Open Source projects on Sourceforge; the support you receive here will be invaluable.
OK, so you've registered your Sourceforge project and set the status to '0: Pre-Thinking About It', what's next?
3. Don't Waste Time!
Now you need to set up your SourceForge homepage. Keep it plain and simple - don't use too many HTML tags, just knock something up in VI. Website editors like FrontPage and DreamWeaver just create bloated eye-candy - you need to get your message to the masses!
4. Ask For Help
Since you probably can't program at all you'll need to try and find some people who think they can. If your project is a game you'll probably need an artist too. Ask for help on your new Sourceforge pages. Here is an example to get you started:
Thousands of talented programmers and artists hang out at Sourceforge ready to devote their time to projects so you should get a team together in no time!5. The A-Team
So now you have your team together you are ready to change your projects status to '1: Pre-Bickering'. You will need to discuss your ideas with your team mates and see what value they can add to the project. You could use an Instant Messaging program like MSN for this, but since you run Linux you'll have to stick to e-mail.
Don't forget that YOU are in charge! If your team doesn't like the idea of giant robotic spiders just delete them from the project and move on. Someone else can fill their place and this is the beauty of Open Source development. The code might end up a bit messy and the graphics inconsistant - but it's still 'Free as in Speech'!
6. Getting Down To It
Now that you've found a team of right thinking people you're ready to start development. Be prepared for some delays though. Programming is a craft and can take years to learn. Your programmer may be a bit rusty but will probably be writing "hello world" programs after school in no time.
Closed Source games like Doom 3 use the graphics card to do all the hard stuff anyhow, so your programmer will just have to get the NVidia 'API' and it will be plain sailing! Giant robot spiders, here we come!
7. The Outcome
So it's been a few years, you still have no files released or in CVS. Your programmer can't get enough time on the PC because his mother won't let him use it after 8pm. Your artist has run off with a Thai She-Male. Your project is still at '1: Pre-Bickering'...
Congratulations! You now have a successful Open Source project on Sourceforge! Pat yourself on the back, think up another idea and do it all again! See how simple it is?
Re:Open Source Development HOWTO (Score:2)
9. Profit!
Me and my Co-Workers (Score:1, Insightful)
"My Co-Workers and I".
You're new here, aren't you? (Score:4, Informative)
In all seriousness, though, like others have said, look at the various licenses out there (GPL, CPL, LGPL, BSD, CC, MIT) and decide what best fits your needs. You could even consider a multi-license scheme like Mozilla has.
As far as involvement, Sourceforge is a place to put it if you want development to continue. Someone has to admin the project (the CVS repo won't patch itself, and you don't want everyone to have write access), though, so if you don't want to be personally involved, find someone to give ownership of the project to (give the official-ness label to them, not necessarilly have them own the original IP) or put it on Freshmeat.
What do you want to achieve? (Score:3, Informative)
Some ideas of what I mean, first for the licences:
- is it for the greater good, and you don't mind telling people what to do (that's GPL)
- you (or your company) want(s) the credit, otherwise you do not care: look at something like BSD
- how much control do you want to keep over the code?
- do you expect patches, do you expect to use them in a closed-world scenario? (no GPL for you)
There are many more aspects you can consider. Or you don't care. It really depends on what your goals are.The other goal-dependend area is what you want to offer. If you just want the code out there so you can get people you know to download it: plain CVS is fine, forget the rest. Maybe upload a simple index.html onto the homepage.
If you want to reach people, you have to do more. First of all: do a decent (not fancy, but useful) website. You can get away with not updating too often (just don't put news on it if you don't plan to update), but you need a starting point for people. The SF pages and CVS are not nice, although your target audience might cope with it -- your project seems to be for rather experienced people.
How much support do you want to give? I love the support bit, helping people to use my programs gives me the kick :-) My projects thus use multiple mailing list, the webforums, a whole set of trackers (although not actively at the moment, but I will get notifications) and I try to get websites that pick interest. The latter is after all the place where I start looking at projects, and the "not there yet" often causes me to go away. Simple single page is ok, nothing is a killer unless I am really keen.
If you do not want that level of support or none at all -- turn the features off. Some contact email address is sufficient, maybe a mailing list. Noone really _needs_ web-forums and other stuff, they just help getting the casual visitors involved. Doesn't sound like your project, works for mine. Different goals, different audience --> different tools.
And a last one: SF is quite cool and they often surprise me with the quality of support you get for free; but don't expect a nice UI experience :-) The project admin bits are all over the place, sometimes you have to go into a feature section, then Admin, sometimes first Admin, then select the feature. The usual feedback is getting you back to the same page, but some more or less visible red result message somewhere on the page (mostly on top, but not always). It is not too bad, just don't have too high expectations :-)
HTH and wasn't too much of a waffle :-)
Peter
MySQL & License (Score:1, Interesting)
Does it matter if the actual accounting system uses common php and perl modules to connect to the MySQL database? What if the actual project does not directly access any MySQL API and no MySQL product is distributed with it. Say the code contains SQL and calls to php and perl database functions, and it just requires that the system have MySQL installed and a properly configured database. What if the user downl
Hazlenut (Score:3, Informative)
The first thing your project site needs to tell me is what the hell the project is. Acronyms are nice and all but without some real words somewhere it is going to make it exceedingly difficult to tell the difference between MyPBS, phpBB, CBS, NBC, and FBI. This part should be in relatively simple terms with lots of keywords so search engines can easily find and rank it.
Unless it is glaringly obvious tell me what I might do with this. Your project might be just the thing I'm looking for but it also might be almost what I need. I might be able to adapt it and fire off an e-mail to you informing you of my extentions and your project can grow a little bit. If I'm looking for some particular bit of information out of two billion plus pages indexed in Google I'd notice your project if you make it simple for me to find such information.
Next tell me where I can pick up the latest and past releases of the project. I loathe having to skim through SourceForge's project pages to find a particular link to the latest release of some project. A couple of direct links won't kill you and they'll make my life easier.
Once I've got the sucker downloaded let me know how to install and use it. Well written instructions can mean the difference between your project growing and being popular or being stagnant and overlooked. Your potential users shouldn't have to pour over your source code to figure out how to use your software. If you feel static documentation is a little too daunting of a task make a documentation Wiki. Write out your initial set of instructions and such and let your users and developers amend those instructions as needed. Users who couldn't code to save their lives might be able to contribute some clarified instructions or maybe provide usage examples from their own experiences.
Finally provide me with a couple different means of communicating with members of the project team. If you really want to build a nice bit of software make it easy to form a community out of your users. Mailing lists, bulletin boards, and newsgroups help turn groups of overwise disconnected users into a connected community. I personally feel OSS projects work much better when the developers and users have a lot of interaction. With OSS users can often times be unofficial developers which makes this interaction all the more important.
As was already mentioned, your project page doesn't need to be some big parade of multimedia. As long as it conveys the information it is supposed to and is clearly laid out it doesn't matter what you do stylistically to it. If you don't intend to update the page often don't under any circumstances put a contemporary news section. If you feel the need for "news" post the changelogs for your latest releases or maybe a project status section. Few things are worse on OSS project pages than seeing "news" that is more than six months old despite an aggressive release schedule. HTH.
License (In)compatability (Score:1)
One problem you might hit is that Licence X is not necessarily compatible with Licenses Y & Z.
This becomes fun if your project needs to be released using License X, but makes use of libraries published under Y & Z.
For example: Depending on how your code binds [gnu.org] to each library, you may be required to use the same license as those libraries. e.g. you may be required to use the GPL.
So,
My PBS already on sourceforge (Score:1)
Tom.