Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I thinking of a good opensource licence to choose for my project. I got a few requirements but I have a hard time choosing a license because a read some different things about some of them.
The project is a Java project that can calculate decompression schemes for scuba diving. I want this project to be opensource because a wrong decompression scheme can be lethal. Therefore feedback on the algorithms and source code is important for me. I don't make my own algorithms but I use various opensource algorithms that I implement in 1 Java library.
My requirements are:
I and other contributers to the project don't want to be responsible for wrong calculated decompression schemes due to bugs in the code, miss use of the code or any other way that resulted in wrong decompression schemes.
The library should be able to use on a website I plan to build without the need to publish the server side code of the website.
It's not allowed to make any profit of the library itself. Even not even the library is changed and republished. However I don't mind if people sell programs the make use of the library.
If people change the code than they should be forced to re publish the library with an opensource licence (Optional requirement).
I hope someone with a bit more knowledge of licenses can help me out.
Well, there are a couple of things I notice right off the bat here.
First off, you talk about needing to be able to do things with your own code. If you are the copyright holder, you can do pretty much anything you damn well please with your own code. The license is for other people, not for you.
Also, disclaiming any responsibility for what the code may do to other folks is pretty much boilerplate with any license.
That being said, I've found in my work I can get by with the use of only 3 different kinds of licenses, depending on my needs.
Full on GPL
Benifits:
Nobody can ever take any of the code propreitary (without coming to me for a relicense). They can still use it and charge people, but since they'd have to license the result GPL, that wouldn't be particularly practical. The reason is that any of their users could give away all the free copies they like.
The sources are avilable for anybody to contribute to, so I might not have to find and fix every damn bug and write every new feature myself.
Drawbacks:
None of the code is usable in a properitary app
I use this typically for stand-alone apps.
GPL with linking exceptions
This is basically what it says; GPL with an exception that meerly linking against (or #including) the code does not render the entire result GPL. Here's an example from the Classpath library.
Benifits:
Nobody can ever take the code itself proprietary.
The code can be used in a proprietary product without making the whole closed-source product open-source. Only the GPL-licensed stuff has to stay GPL.
Drawbacks:
The facility itself can never be expanded into a proprietary facility. Generally a plus in my book, but it does deter some people from using it.
I use this typically for helper facilities and API's .
Public Domain
This means anyone can do anything they like with this code, including making a tiny tweak, slapping their own copyright on it and calling it theirs.
Benifits:
Anybody can feel free to use it however they like.
Drawbacks:
No protection from the code getting "stolen" by a proprietary software seller.
Impossible to do in may jurisdictions (a permissive BSD I understand can be a good alternative there).
I use this when I'm publishing something incomplete that I really want someone else to take over, or when publishing something that is supposed to be a reference implementation for a standard library.
Now in a case like yours what I would do is either:
Use GPL with the linking exceptions for the library. That will allow everyone (including you) to use the library in a proprietary application, but the library itself will always stay Free.
Use GPL, and insist that contributions from others have their copyrights assigned back to you. This allows you full rights to make your own proprietary app using other people's contributions, and doesn't allow anyone else (including those contributors) that same right. Kinda cheesy in my book, and will probably discourage outside contributors. However, only the most successful Free Software projects get any outside contributors anyway. So it may not be that much of a loss.
It came to my attention recently that Bruce Perens (one of the founders of OSI) actually made a blog post a year earlier that made the exact same point. He picked two different licenses than I did for the latter two though. He picked LGPL for the intermediate license, which I think is a mistake on his part. However, he picked the Apache License 2.0 for the latter license, and I think he may have a point on that one. The benefit you get from using Apache over straight Public Domain is that you are better protected from patent lawsuits. That isn't something poor little me really has to worry about, but your company is a different matter entirely.
This impossible. You say you want an open source license that prohibits making money. However, one of the key requirements for being an open source license is not making any restrictions with respect to commercialization.
Ergo, a license like you describe it cannot possibly exist.
And here the standard answer: StackOverflow is a site for programming questions. We are programmers. Your question is a legal question. This means that all answers (including mine) will be, by definition, crap, since we don't know WTF we're talking about.
For legal questions, ask a lawyer.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am a web developer, and I don't have enough knowledge about software licenses. I wish to publish some of my works, and I need to select licenses for them. My software product is free of cost, but I have some restrictions on distribution/modification of the code.
It’s free of cost (but donations are acceptable).
The source code is freely available. You can use, customize or edit/remove code (as long as the basic nature of the software is not changed).
You don’t have any permission to change the product name.
There are some libraries and classes which are in a folder called “myname”. You don’t have permission to rename “myname”.
You can contribute any additions or modifications to my project, to the original source repository (the contributor’s name/email/site link will be listed in the credit file).
You can’t remove the original author’s name from the license.
You can put the license file or license code anywhere in the project file or folder.
You can redistribute this code as free or commercial software.
Are all these restrictions valid? Given these restrictions, which license should I use?
My main intention is to make the product more popular with free source code while ensuring the original author is not ignored. The product is open.
Thank you all; the above points are because of my lack of knowledge of license terms.
You can help me to correct or remove some of the above points. What I’m basically looking for is in the paragraph above.
I don't think the following are currently covered by any license I am familiar with:
Don't deviate from the basic nature of the software.
You can use/customize/redistribute as free or commercial, but you can't change the name.
I'd argue that while the product may be free and "source code available", that what you're describing is not "Open Source". Notably, you're not letting people fork and/or repurpose the code, both of which are main features of an Open Source code base.
By retaining copyright, no one can "take your name off" of your code, as they don't possess copyright, but not being able to rename the project, or change the names of folders, that's pretty extreme.
So, I would suggest you think through your motivations behind releasing the code and from where these restrictions originiate.
As others have noted, you have some rather odd requirements:
“Don’t deviate the basic nature of the software.” (Do you specify the “basic nature of the software” in the program itself, and are you going to argue in court over something so vague?)
“You don’t have any permission to change the product name.” (Usually, if anything, the opposite is required: if you change it, you have to change the name, so people don’t think that the modifications represent your work.)
“There are some libraries and classes which are in a folder called ‘myname’: you don't have permission to rename ‘myname’.” (Similar to the first, but more concrete — though I’m not sure what the point of this is.)
Based on these requirements, I think the license which fits most closely with your stated desires is the GNU Free Documentation License. As indicated by the title, it’s almost never used for source code of programs.
It is the only license I know of which allows you to prohibit users from changing or improving specific parts of the work. For example, I think you could say that the folder “myname” is an “invariant section” (note that I am not a lawyer, and this is not legal advice).
It’s not compatible with the GPL, and (the way you’d use it) it’s not DFSG-free. It’s rarely used for software, so distributors and contributors might have trouble understanding how to apply it. In short, you probably wouldn’t be making any friends with this route.
BSD license should cover this. I have chosen it for my open-source stuff too.
As written your requirements don't fit into any specific license out there (that I know of), and since you are not looking to make money, getting a lawyer to draft one would be rather expensive, and fundamentally counter-productive.
I suggest you look at licenses for different open source projects out there and see which one matches closely with what you want, and use that.
To get everything you want you will probably have to write your own license. This is not necessarily in your best interests. You are going to have to make a choice between popularity and control:
If you use an established license, you will have a very wide audience for your work, which will have a chance to become popular.
If you insist on certain restrictions (the name can't be changed) you will keep greater control, but you will lose potential users; because lots of organizations won't look at software with a nonstandard license.
Your requirements are very close to BSD, and not that different from MIT. I recommend you browse the popular licenses blessed by the Open Source Initiative and choose the one you feel is closest to your desires. I've checked your edits, and if you insist that I make a recommendation, for your wishes I recommend the Simplified BSD license. It's a good, popular license that is often used by developers who want their work to be very widely deployed.
If you ask people in a README file not to fork your software and change the name, as a matter of personal preference rather than licensing terms, most people will honor your wishes.
I think you will have a hard time finding an existing license to fit your needs because you seem to require two separate sets of permissions: a MIT-like set of permissions for the source in general, with the exception of a locked-down "myname" folder. You may be better off separating your code into two separate parts, each with a different license. The MIT license seems to fit your conditions for the bulk of the code (except for the "basic nature of the software" statement, I'm not sure what you mean by that). The MIT license requires the copyright statement bearing your name to be retained in all copies of the source, so this would address the concerns you bring up in your first edit. Depending on the particular reasons why you need to add special restrictions for the "myname" folder, you may have to write a custom license (you can take an existing one that's close and simply tweak it) that governs only that folder. Your entire project doesn't have to fall under a single license.
3) You don't have any permission to
change the product name.
You might be asking for problems with this one. If someone takes your code, enhances it, and releases it with the same name then you will have two very different programs out there with the same name. This is very confusing for potential users. Is the the original version? The version that was modified with a German-language interface? The version that has a fix for a specific bug? When they all have the same name, it's difficult to determine. If a user has a bad experience with a particularly buggy (or worse, virus-infected) derivative work, they will be unlikely to use any version of your software because it appears to be the same program as the buggy version.
I get the impression that you are mostly wanting to avoid having your work copied and completely re-branded without any acknowledgment of your involvement. I might suggest that instead of prohibiting name changes, require that derivative works reference your original product name (for example, "ShinyNewProgram - Powered By YourOriginalName"). Many open-source projects trademark their product names and a provision like your #3 would then be a violation of trademark law; the more common solution is to require a new name (to differentiate it from the original) and to require clear attribution of the original work.
We have a number of AS/Flex components that we've built over time and improved upon. They've been turned into components so they can be reused in different projects and save us time. So you can think of them as part of an in-house framework of sorts.
We're now realizing that it doesn't make sense to release the source code for these components to the various clients as part of the project, because technically this code isn't really owned by the clients.
So my question
When a client comes to you, how do you explain to them that you can't give them the full source code for those components. The client doesn't understand the difference, he just expects you to give them all the code for the site that he paid you to do. He doesn't understand that this code has taken you a lot longer to write than what he's paying for his site. But since he doesn't understand, he would get turned off and thinks you're ripping him off or something.
How do you handle this situation? What do you tell clients upfront? Do you advertise it on your site from the very beginning? How do you handle their objections so they still hire you?
As a side question, how often do you give AS and Flex source code to your clients? In the case when the code doesn't have any in-house components that you reuse in several projects, and in the case when it does have in-house components.
I'd also like to hear from people who've worked at creative agencies since they're most likely have run into that issue already.
I'd explain to my client how the world works. I'd use examples, analogies and metaphors.
This isn't a software-development issue, this applies to all products. Some things are sold as black-box, and some things are sold as a clear-box containing black-boxes inside it.
Lets say you wish to buy a house. You pay the engineer and the architect for their work, and you gain the documents they produce. These documents contain information that relies on other pieces of information, which you do not gain. For example, the engineer may use huge steel bars in his plans. The engineer's specifications determine the qualities that each steel bar must have, but they do not specify how the steel bars are created. Buying house plans doesn't buy you the plans for creating the house's building blocks.
With softwre it is pretty much the same: you don't get the source code for the .NET framework when you buy a .NET application "with sourcecode included". What you do get is the .NET documentation, specifying how to work with the framework (and not specifying how the framework does what it does).
The amount of examples is actually endless, because - as stated above - this is the way the world works.
Build your own analogies to fit your scenario. Explain to your customer where the infrastructure ends and his owned solution begins.
quoo is right about the need to specify these in the contract. The contract is the legal backbone of the deal. But i'd like to emphasise the fact that pointing at the contract should be a last resort. If you can give your client a reasonable explanation such that lets the client understand why things are the way they are, you won't need to wave the contract (which speficies only the way things are, without the motivation, explanation, etc.).
I'm not a business person, but generally these things are specified in the contract. If your contract stipulates that you provide the client with the source code at the end of the project, then at the very least, you should be providing them with swcs of your components so they can recompile the code if necessary. If you don't want to share your code with the client, then that too is something that you'll need to specify up front.
Just explain that you can not provide the source for external libraries that you used on his project to make the bid cheaper for him. He would not expect the source from a 3rd party vendor that you used in his project, just try to explain this is the exact same situation.
Intellectual property issues should be covered upfront as part of the contract. I'm not a lawyer but common practise is to specify:
Which components are provided by third parties and refer to their licensing terms
Which code will be produced as part of the contract.
Whether you license or sell various intellectual property rights.
Licensing terms.
Intellectual Property laws` are complex and diverse, they differ from country to country. Depending where you're and where your customer is the licensing terms might need to change. As an example, reverse engineering viewed differently in different jurisdictions.
Apart from third-party components and software bits you don't want to sell, nor give an exclusive license for you'd probably want to be able to exhibit and distribute the works as part of your company portfolio. This latter activity would also need to be covered within the contract.
Having a well written contract prepared up front will save a lot of misunderstanding and unnecessary negotiations. You'd probably need just one template you could use for all your customers. So my advice really is "talk to a lawyer".
Your contract should make clear that components developed by you are licensed to the client for use as part of the project and only the project(s) you did for them. Of course, you'll need to determine the exact language for yourself and the situation, but if you're repeatedly using these components in your projects, you really ought to have some sort of boilerplate for just this situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I work at a company where the rule basically is (as I understand it) that you cannot use any code unless (a) you write the code yourself or (b) there is some explicit indemnification clause guarding your use of any other code (like open source code). I am finding this making my coding difficult.
For example, coding samples in books are pretty much use "as-is". Microsoft SDK Code Samples are use "as-is". Blog posts about coding are use "as-is". There are several sites out there with code samples (including SO) that are use at your own risk. No warranties implied or indemnification against intellectual property lawsuits, blah, blah, etc.
Basically, I'm confined to using Asp.Net and the .Net Framework and nothing else and to bar my eyes from accidentally picking something up that I haven't created (ok...that may be my anal interpretation of the rule ;-).
I find this difficult because a big part of learning to code I think is reading other code. Reading blogs that have code, reading books that have code, looking at coding samples, using code from SDK samples etc. Also, I would think it is safe to use code that people have shown to be a good solution or pattern for something and freely put up for others to use. I'm not about to think that I can code everything myself. I definitely have to stand on the coding shoulders of others to reach certain heights.
It could be that I don't understand licensing very well either. From the companie's perspective (I suppose) they don't want to incur any risk of beind sued for IP infringement.
My thought is that you have to weigh risks. Taking a coding snippet from a book is low risk. Incorporating code from an open source library could be high-risk. I say make decisions based on how much risk you are willing to take.
Has anybody had experience working in a situation like this or similar to this? Is this a rare thing or is it common in some sectors? Are there others in the same position like me out there?
Any insight or guidance would be appreciated! Thanks!
Edit:
Thanks for the responses! To clear up some things: I'm not advocating stealing code. I'm talking about code that has some kind of public license that allows it to be used in its defined legal way. The key is there is no indemnification in public licenses in using the code. That means it you use it at your own legal risk (and other risk). If someone sues an open source project that you used code from, you could be roped into the lawsuit as well because you are using the code even though it had a public license.
In 2005, Microsoft was using indemnification to compete against open source venders by promising it's partners that Microsoft would protect them against IP lawsuits. http://www.microsoft.com/presspass/press/2005/jun05/06-22PartnerIndemnificationPR.mspx
So, even if the risk of being sued for IP infringement may be extremely low, it is a non-zero probability. Thus, I can't use any of it. Even if it has a public license of some sort. :-(
The "risk of beind sued for IP infringement" isn't really the right way to think about it. This isn't a "risk" thing.
Either
You have a license and can use the source. There's no risk. You have the license. There can't be a lawsuit.
Or
You don't have a license and you're in violation. Effectively, you will be sued. There's no risk here, either. You're in violation of someone's copyrights (or worse).
Companies are averse to Open Source for a variety of strange reasons. Risk of lawsuit is not one of them.
Things I've heard.
What if it has a virus?
What if it doesn't work as advertised?
What if it "crashes" something? Who do we sue?
None of these are "risk" items. They're "due diligence" items. And mostly, they're easy to address: pick products with enough users that someone else vets the code before you; QA open source as if one of your own people typed it in. Except for one.
This leads us to the real reason. [Hint: It's not "risk of lawsuit".]
There's no one to sue when you didn't perform due diligence on open source.
Most shops don't have real solid configuration management or QA policies (the kind that would stand up in court as best practices). Until they have these things in place, they don't dare think about introducing open source for which you really need solid QA and configuration management.
I think what your company is really worried about is you directly copying large segments of code for which there may be licensing issues, presenting a legal problem to the company if they are caught using it. However, you may read blogs or other non-licensed code and discover a solution which works for the particular problem you are working on. In that case, you would be better off rewriting the code (that is, look at the solution and reproduce it) as opposed to just copying the code and making modifications to it. At my company, that is what they generally recommend for using non-proprietary code.
As well, for small amounts of code (e.g. a standard implementation of a cache) where everyone implements this the same way, every time, your company is unlikely to be afraid of using outside code, as long as you are sure to test it carefully.
By "indemnification", I assume they mean assurance that the code is free of copyright or patent or maybe trade secret encumbrance that they don't know about up front, or that somebody's willing to compensate them if something like that turns up. I've never been in a company that worried about this, nor have I heard of one before.
It's not clear what you actually want here, other than sympathy (and I do have sympathy for people trapped in corporate foolishness). It sounds like the policy is quite rigid, if you're worried about sample code in books. This is a bad policy, and will hinder you, but I don't know what you can do about it. Unlike Joel's blog post on getting things done as a grunt, it sounds like you can't just start doing thing intelligently without being in clear violation of corporate policy.
Not knowing your situation, my suggestion would be to look for another job. This one will definitely stifle your professional growth, and a company with that policy is unlikely to be reasonable about it.
(It would be nice if you could assure them there was no danger, but that's not true. People have lied about copyrights, although open source projects tend not to, and only a fool would claim definitely that a large chunk of code did not infringe on any patents in the US; even if it was written a year before software patents were first awarded, that would be merely good grounds for a court fight, rather than avoiding a court fight. GPLed software is actually better than BSD software, since it requires some patent licensing downstream, but it can't deal with third-party patents. Of course, if they're that worried about being sued, writing in-house software is no solution. That can infringe on patents.)
You could rename the variables and how would they find out? Do they check every line of code ? Universities tell you that all the time, not to copy code without referencing. Why don't you try coding something and useing parts of code you find in the Internet?
Generally you will use more from communities like stack overflow or blogs than from open source projects.
Finally since the code has no warranties, its at your own risk.. well the is the same case if you came up with the code by yourself: its at your own risk.
Hope that helps... and good luck.
It could be that I don't understand licensing very well either. From the companie's perspective (I suppose) they don't want to incur any risk of beind sued for IP infringement.
My thought is that you have to weigh risks. Taking a coding snippet from a book is low risk. Incorporating code from an open source library could be high-risk. I say make decisions based on how much risk you are willing to take.
I'm not sure if I understood correctly. If you are saying that license infringement is fine when you don't get caught, I will have to disagree with you.
You can learn by reading code without breaking laws or getting fired. Just don't copy the code to your company's code base if the license doesn't allow it.
If you're not aware of the "clean room" concept, then there's always that approach. Have a friend look at some open source code and get them to tell you how they think it works. Diagram it out, and then code it yourself.
If it worked for IBM, right?
Keep in mind that not all Open Source is GPL. Your company can copy as much BSD-licensed code as they like. BSD-licensed code has made it into OS X (that's probably my biggest understatement of today) and to a lesser extent Windows NT.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We have a series of closed source applications and libraries, for which we think it would make sense opening up the source code.
What has been blocking us, so far, is the effort needed to clean up the code base and documenting the source before opening up.
We want to open up the source only if we have a reasonable chance of the projects being successful -- i.e. having contributors. We are convinced that the code would be interesting to a large base of developers.
Which factors, excluding the "interestingness" and "usefulness" of the project, determine the success of an open source project?
Examples:
Cleanliness of code
Availability of source code comments
Fully or partially documented APIs
Choice of license (GPL vs. LGPL vs. BSD, etc...)
Choice of public repository
Investment in a public website
There are a several things which dominate the successfulness of code. All of these must be achieved for the slightest chance of adoption.
Market - There must be a market for your open source project. If your project is a orange juicer in space, I doubt that you'll be very successful. You must make sure your project gets a large adoption amongst users and developers. It is twice as likely to succeed if you can get other corporations to adopt it as well.
Documentation - As you touched on earlier documentation is key. Amongst this documentation is commented code, architectural decisions, and API notes. Even if your documentation contains bugs, or bugs about your software it is ok. Remember, transparency is key.
Freedom - You must allow your code to be "free" - by this I mean free as in speech, not as in beer. If you have a feeling your market is being a library for other corporations a BSD license is optimal. If your piece of software is going to run on desktops then GPL is your choice.
Transparency - You must write software in a transparent environment. Once you go open source there is no hidden secrets. You must explain everything you do, and what you are doing. This will piss off developers like no other
Developer Community - A strong developer community is required. This must be existing. Only about 5% of users contribute back to the project. If someone notices there haven't been any releases for a year they wont think "Wow, this piece of software is done," they will think "developers must of dumped it." Keep your developers working on it, even if it means they are costing you money.
Communications - You must make sure you community is able to communicate. They must be able to file bugs, discuss workarounds, and publish patches. Without feedback, it is pointless to opensource the project
Availability - Making your code easy to get is necessary, even if it means pissing off lawyers. You have to make sure your project is easy to download, and utilize. You don't want the user to have to jump through 18 nag screens and sign a contract in order to do this. You have to make things simple, and clean
I think that the single most important factor is the number of users that are using your project.
Otherwise its just a really well written, usefull and well documented bunch of stuff that sits on a server not doing very much...
To acquire contributors, you first need users, then you need some incompleteness. You need to trigger the "This is cool, but I really wish it had this or was different in this way." If you are missing an obvious feature, it's extremely likely a user will become a contributor to add it.
The most important thing is that the program be good. If its not good, nobody will use it. You cannot hope that the chicken-and-egg will reverse and that people will take it for granted until it becomes good.
Of course, "good" merely means "better than any other practical option for a significant number of people," it doesn't mean that its strictly the best, only that it has some features that make it, for many people, better than other options. Sometimes the program has no equivalent anywhere else, in which case there's almost no requirement in this regard.
When a program is good, people will use it. Obviously, it has to have a market among users--a good program that does something nobody wants isn't really good no matter how well its designed. One could make a point about marketing, but truly good products, up to a point, have a tendency to market themselves. Its much harder to promote something that isn't good, so clearly one's first priority should be the product itself, not promoting the product.
The real question then is--how do you make it good? And the answer to that is a dedicated, skilled development team. One person can rarely create a good product on their own; even if they're far better than the other developers, multiple perspectives has an incredibly useful effect on the project. This is why having corporate sponsors is so useful--it puts other developers' (from the corporation) minds on the problem to give their own opinion. This is especially useful in the case that developing the program requires significant expertise that isn't commonly available in the community.
Of course, I'm saying this all from experience. I'm one of the main developers on x264 (currently the most active one), one of the most popular video encoders. We have two main developers, various minor developers in the community that contribute patches, and corporate sponsorship from Joost (Gabriel Bouvigne, who maintains ratecontrol algorithms), from Avail Media (who I work for sometimes on contract and who are currently hiring coders on contract to add MBAFF interlacing support), and from a few others that pop up from time to time.
One good developer doesn't make a project--many good developers do. And the end result of this is a program that encodes video faster and at a far better quality than most commercial competitors, hardware or software, even those with utterly enormous development budgets.
In looking at these issues you might be interested in checking out the online version of a course on open source at UC Berkeley, called Open Source Development and Distribution of Digital Information: Technical, Economic, Social, and Legal Perspectives. It’s co-taught by Mitch Kapur (Lotus founder) and Paula Samuelson, a law school professor. I have a long commute and put the audio of the course on my iPod last year – they talk a lot about what works, what doesn’t and why, from a very broad (though obviously academic) perspective.
Books have been written on the subject. In fact, you can find a free book here: producing open source software
Really, I think the answer is 'how you run the project'.
All of your examples matter, yes, but the key things are how the interaction between developers is managed, how patches etc are handled/accepted, who's 'in charge' and how they handle that responsibility, and so on and so forth.
Compare and contrast (the history isn't hard to track down!) the management of the development of Class::DBI and DBIx::Class in Perl.
I was just reading tonight an excellent post on the usability aspect of successful vs unsuccessful open source projects.
Excerpt:
A lot of bandwidth has been wasted arguing over the lack of usability in open-source software/free software (henceforth “OSS”). The debate continues at this moment on blogs, forums, and Slashdot comment threads. Some people say that bad usability is endemic to the entire OSS world, while others say that OSS usability is great but that the real problem is the closed-minded users who expect every program to clone Microsoft. Some people contend that UI problems are temporary growing pains, while others say that the OSS development model systematically produces bad UI. Some people even argue that the GPL indirectly rewards software that’s difficult to use! (For the record, I disagree.)
http://humanized.com/weblog/2007/10/05/make_oss_humane/
Just open-source it. Most probably, nobody will start contributing yet. But at least you can write on the press-releases that your product is GPL or whatever.
The first step is that people start using it...
And maybe then, after users get comfortable, they will start contributing.
Everyone's answers have been good so far, but there's one thing missing and that's good oversight. Nothing kills an open source project faster than not having some sort of project management. Not to tell people what to do so much as to just add some structure and tasking for the developers you are hoping to attract.
Disorganized projects fall apart fast. It's not a bird you just let go and watch it fly away.