Slashdot Mirror

← Back to Stories (view on slashdot.org)

Challenges in Releasing Open Source Software?

Posted by Cliff on from the determining-the-hurdles dept.

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

4 of 24 comments (clear)

  1. A few thoughts by dedazo · · Score: 4, Informative
    Hurdles: Since you seem to already have clearance to release this (I assume you're not the lone developer), there's not much trouble there. Just make sure that you do have full permissions to release it.

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

    --
    Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
  2. You need to review the MySQL licensing scheme by millisa · · Score: 5, Informative

    MySQL has changed their licensing recently and they are very restrictive about which OSI Approved licenses are acceptable for use with their product (without paying the licensing fee). If it's not GPL, you are likely going to have issues. They have a very short list of what does and does not qualify. However, they are responsive when you write them at licensing@mysql.com (albeit it took several days) when you need clarification.

    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.

  3. Glad you asked! by Yaztromo · · Score: 4, 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) up on our project site at SourceForge (http://sf.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), 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:

    • Don't skimp on documentation. Good user and developer documentation can make or break your project. Complex projects that other developers can't easily get into because of poor API and developer documentation can slow development and developer acceptance of your project. Likewise, poor end-user documentation can likewise stymie uptake.
    • Setup a discussion mailing list/online forum and post into it whenever you make an updatee or new release. When starting a new project, users are often leery of empty forums devoid of activity. So be sure when you start your project to generate your own activity until you attract users. Some users base their perceptions of the activity of a project on its public user community, so list/forum traffic is good.
    • Release early, release often. Plan your "final" releases, then release various alpha/beta releases whenever you add something new. In this way, your project will be percieved as active by potential users. Daily updates to your CVS repository won't really matter if your last file release was three years ago -- not every user wants to get code from CVS.

    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.

  4. You're new here, aren't you? by magefile · · Score: 4, Informative

    I mean, asking about license choices on Slashdot?

    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.