I have an API library for C# that provides flexible multithreaded task management of objects on task bases. The library was developed extensively for a project that was later cancelled by the client. I received the legal rights to the library, and the client doesn't care what I do with it now.
I don't know what to do with this source code.
Can you please explain to me, what the steps are in taking source code and making it a successful open source project? How do you attract developers? How will people know the library exists?
EDIT:
The reason I ask this question, is to bring the source code to an open source state. I'll be adding a full set of unit tests, documentation, examples, etc.. etc..
That represents more investment of my time, and if there is no pay off "i.e. no one uses it". Then what's the point?
Best Answer
To get started is actually pretty easy, after that, not so much...
Step 1 - Choose a License
OSS licenses are like... noses, everybody's got one and it's important to choose one that will foster progress. If you have questions about the nuances of a particular license you'll probably want to take a look at The Open Source Initiative website. You can find the legalese for the majority of the most common OSS licenses there and the comments are a good place to figure out the nuances.
The most common licenses in use are GPL, MIT, BSD, Apache, etc... All of them ensure freedom to work on the source code but many have terms about how they can be extended and/or used in commercial software. IMHO, the two extremes of the 'freedom' scale are the GPL and MIT licenses.
GPL:
The upside is that it states that any open source included in a project needs to be made freely available to the public. That means, when Open Suse releases a new version with their proprietary extensions, they can sell you one version in a box but they have to have a link to the open source code buried somewhere on their site.
This is the one people are referring to when they accuse OSS of being 'viral' in nature. That's because if you include GPL code into your own personal project, your project has to either use the GPL or a more 'copy-left' (ie liberal) license or your violating the terms.
Richard Stallman basically created it as a response to all of his super-smart friends walking away with 'open source' code they had been working on to make massive amounts of money in the commercial world. I like to call it the 'Stickin it to the man, man...' license or 'Revenge of the Neckbearders'.
GPL is largely popular because it has become the ideological platform for OSS evangelists. Many people initially adopt it because they're not sure where to look for an alternative or they don't read the terms closely enough. Some choose it reluctantly but hold it at arms length.
If you're looking for some cheap entertainment, grab some popcorn and Google 'Linus Torvalds GPLv3'. Linus is known to be vocal and have strong opinions about things that piss him off. This topic just happens to be one of them.
MIT:
On the other end of the scale is the MIT license. It's the Ayn Rand of OSS licenses. It basically states that you can do whatever you want with the code as long as you maintain that the code is licensed under MIT. No requirements to provide source code, prevent extending the code, making money, nothing.
It basically says, 'I made some useful code, you can make use of it without worrying about me suing you.' This is my personal favorite because I don't like to have to fret about legalese.
LGPL:
If you're designing an API, this is the best of both worlds. It's GPL for libraries. Basically, they have to share the source code but they can include the code as a module/dll without affecting the license of their project. It also maintains that you can't change/extend the code without offering those changes back to the project. It may seem like a dickish clause but it prevents people from providing wholesale forks of your codebase and diluting your userbase.
Step 2 - Setup Source Control
Due to the geographic problems with OSS development, it's ridiculous develop without some sort of source control. The key thing to consider initially is how you'll accept code from others. Some are tempted to give write access to other developers but don't consider why that may be a bad idea.
Think of it like this. Have you ever built a sand castle as a kit only to have some little prick stomp on it as soon as you walked away. That's what you want to protect your project from.
With a CVCS the workflow is simple. Accept change patches and incorporate them as a commit. DVCS, is more complex but a lot more useful for OSS because anybody can commit to their personal repository. Patches are messy and inconvenient. Project members that want to do more extensive work will usually setup their own repository and request the manager to pull the changes in as a branch for review directly. What you choose depends on your preferences.
Step 3 - Choosing a Host
There are plenty of hosts. It usually depends on what you're trying to do with your project.
GitHub:
If you want something more developer-centric with a massive community where everybody will be forking the hell out of your code and making changes. GitHub really accelerates the development/improvement of a codebase but it provides little/nothing for non-developer users. If you want your code to be hacked on a lot and you're comfortable with using Git, this is the way to go.
SourceForge:
If you want something with a more stable project-based development model. They have everything you'd expect to foster good developer/user interaction. Such as, website, forums, mailing lists, etc...
This by no means an exhaustive list. But there are plenty places on StackOverflow, Programmers and Wikipedia where you can find more detailed info.
In fact steps 1-3 all go together because they hosting will dictate what types of source control and licenses you can use.
Step 4 - Profit
Seriously though, building a community around an open source project is extremely difficult. Unless your code magically cures Cancer/AIDS/Malaria and can increase the size of a certain member, people will most likely ignore it. Like everywhere else, it doesn't matter how brilliant and ground-breaking your code is, if you can't 'sell' it to people, they're not going to waste their effort to try it out.
What you need is a strong demonstration of your code's use. Not just a fancy write-up but an actual working demonstration that people can play with on their own.
Even with earth shattering demos, nobody will use it if they're not aware of it. That means you need to actively promote your project, or find others interested enough to do it for you.
Lastly, you need to zero in on the domain your project is addressing. Multi-threaded task management sounds kind of generic. Are you addressing OS tasks or a queue of program tasks that need to be executed? What does your interface/API consist of? Can you load tasks over a network?
And the million dollar question, 'Are there other projects that accomplish what yours does, but have a large community and/or are better implemented.' Just because you had a 'really great idea' doesn't mean there weren't 100 other people who had the exact same 'really great idea'.
You can get away with having no community to start if your code is better but don't expect everybody to jump ship right away. OSS is like trying to create a business with absolutely no marketing. Creating good documentation and 'spreading the word' is as important or more important than writing the actual code.
Aside:
I like to think of open source projects as any other good idea. Initially, you have a moment of enlightenment/clarity where you could see your idea applied to everything. It's so good that you'd be doing a disservice by not sharing it.
I'm pretty jaded but every time I hear people talk about a good idea like a fairy farted magical dust on them I can't help but to snicker. The idea that you can have a good idea that magically transforms into billions of dollars and supermodel girls throwing themselves at you is so ingrained into our consciousness that many people accept it as canon.
It's really common to hear that most Open Source projects were created to 'scratch and itch' because the authors who originally created them did so to provide a functionality or quality that they couldn't find anywhere else. They kept working on it because they needed it. They stayed after they didn't need it anymore because they liked the positive feedback they received from the community. And it survived after they left because the community valued it enough not to let it die.
The greatest danger to new Open Source projects now is the sheer number of dead projects that still exits on the web. I'm talking about one-offs where the developer spent a few weeks hacking, didn't finish building a working implementation, and haven't touched the code in 5+ years. I get the concept that 'the internet never forgets' but finding good (ie active) open source projects that aren't abandoned tomorrow gets herder every day. Don't be disappointed if people don't immediately adopt your code. If they know what they're doing, they'll check when the project was created and how active development has been before they decide to start actively contributing code. Nobody likes to ride a sinking ship.
If you have a project that you like working on, put it out there, it doesn't hurt to try. Like all good thing it requires hard work and determination, supermodel groupies notwithstanding.