Transferring the Leadership of Open Source Projects? 128
Another well timed submission on this same subject, mrgrumpy follows up with this query: "Quite some time ago (around 1997-1998) I built a Java based adventure
game called World.
Developed with Java1.1 (and at the time it was fairly leading
edge, it now looks a bit tired), you run around, collect treasure and kill things. As with all my great projects (hey, I won a Sparc5 for this), I had always intended to finish it,
but never did. Now I want to give it away to a good home where developers will continue to work on the code and bring my ideas to completion.
Every now and then I sit down and have a look at the code but I don't
really have the energy left to complete it (most of my energy was soaked up with my Masters degree). Other projects have taken over now, and I'm planning to go overseas for 12-18 months, so I know I won't get back to it for a very, very long time in any serious way.
I am happy to give the code away if a team of developers want to continue developing it. I can act as a grandfather figure to the project to give guidance and wisdom, and to clarify what my vision was, and what the code does. I'd prefer it to be GPL'd or a
similar license that won't shut the code up.
There was another project similar to this one called White Orb, which seems to have gone the way of the dodo, a shame because it had a lot of potential, so I don't want to release this one and have it gather dust. I could set the project up somewhere like SourceForge,
but as I said I'd rather just hand it all over to someone else and just look after it.
If you're interested, you could email me, or just leave a comment below. I want to pick either a team, or an individual
who I can be confident in that they'll get the project up and running."
So here are two projects looking for good homes. What's the best way of giving up control of an Open Source project (with the potential of varying degrees of continued project development by the original maintainer) in the hopes of it continuing on in good health?
rule number one (Score:5, Insightful)
-sam
When I have someone take over... (Score:5, Insightful)
Does it really need improvement? (Score:5, Insightful)
You say that the application is sufficient for your own needs. Isn't that enough? Rest on your laurels, and be satisfied with the project as it is. Don't go looking for someone to take it over, if someone is truly suited for the task, they will come looking for you.
Unlimited growth is the creed of the cancer cell.
hard (Score:5, Insightful)
Re:rule number one (Score:3, Insightful)
Come now, be honest (Score:5, Insightful)
Take a long look through the projects on SourceForge. Notice anything? That's right, most of them haven't been updated in well over a year, and most of them are being run by one person on their own.
Although open source projects hold great potential for cooperative development, it seems that in the real world there are few bazaars and plenty of lonely coders working on their own projects. Some of these are lucky enough to generate interest, but most don't. Then again, most aren't particularly novel anyway.
The truth is that there are a million projects out there, some of which are more far more [sourceforge.net] worthy [sourceforge.net] and interesting than the things suggested here. And if people are looking for something to contribute to, then they're going to go for these high-profile projects rather than someone's home-grown application.
So I guess you'll be lucky to find anyone to take these over (well apart from posting it on /. perhaps). Open source is great, but it only works for projects interesting enough to generate "many eyes" rather than someone's personal hobby code.
not necessarily (Score:3, Insightful)
What might well "die" is the evolution of the product; a user patching their own code is not likely to go through the effort of propogating their patch, when there's no active maintainer who they can simply email. The project may well end up not evolving further because of this, but hey if the program is mature, that isnt too much of a loss.
And then eventually someone might come along with an idea that uses the "stale" project as a seed for something greater, and start evolving it again.
Wait for somebody to come to you... (Score:4, Insightful)
Wait for somebody else to have an itch to scratch. The idea that you need to "appoint" a new leader is contrary to the non-heirarchical nature of open-source.
Michael Chisari
dominion@tao.ca
walk away (Score:2, Insightful)
easy (Score:3, Insightful)
"I have given up working on this software. You are free to use it as usual. It works fine, and I can't think of anything else I want to do with it. If you'd like to take over the project and add new and exciting features, please contact me at [insert email here]. Cheers."
What's the problem?
Consider a BSD license (Score:5, Insightful)
However, as the code is Free, anyone can take it and use it. It appears that you are looking for free labor to do your bidding. Sorry, the world doesn't work that way. You can close up your code and it dies, or you can put it out there and hope that someone will do something with it.
With the BSD license, someone may take your code and use it, even if in a non-free capacity. With the GPL, they may use it but only in a free capacity.
You aren't interested, so move on. If you want others to benefit from your work, make it easy to find (properly built web pages to search engines can find it) and place it out for the world.
Maybe someone will use it, maybe not. Maybe they'll e-mail you questions, maybe not.
If you're done however, accept it and move on.
If there was a large team of coders working on the project, than this question makes sense. If you were providing genuine leadership, it makes sense to find a replacement.
However, they appear to be software projects that you are done with. Put the code up there. People can use it, or not. People should download it, decide where to go, and setup a fork. If you are lucky, 2-3 projects will form using your code. If not, none will.
Regardless, there is no maintainer/leadership issue, as these are solo projects.
Best of luck,
Alex
Re:rule number one (Score:5, Insightful)
This first guy said outright that a lot of people have downloaded his application but few have submitted patches back to it. That flatly contradicts your suggestion. And as for the second guy, he doesn't sound so different -- he still seems to want to run things, he just wants a break from the tedium of actually writing the code. Boo frickin hoo to him, I say -- if this Java game is his baby he shouldn't expect someone else to care about it as much as he did. It's much easier for me to sympathize with the CVS guy -- he's done what he set out to do, now he's willing to let others go where they will with it. If the project is to continue, this is what will have to happen: some other lead developer (or group of developers) will have to see something in the project that they want fleshed out, so it can become *their* itch to scratch, not someone elses. People don't tend to scratch other peoples' software itch unless they're being paid to do it, which brings us back towards the proprietary model.
What you say sounds nice in theory and adheres nicely to the party line, but the sad fact is that the mechanics of things don't let them work out that way. Only the biggest projects have anything looking like a team effort -- Perl6 comes to mind -- and even then they're being lead by a core group of people, so it isn't really an exception to the rule.
Wanted: free labour (Score:4, Insightful)
Your "vision"? My that sounds pompous. If someone else is willing to take over, they won't want the crutch of having to take orders from someone else; open source is about freedom. If they do take suggestions from you, be happy, but don't think you'll be able to sit there like a god and direct your minions how to code "your" project. When you hand it over, you hand it over. It's not yours any more. And depending on the quality of the code and how finished it is (I quote: "I had always intended to finish it"), perhaps nobody will want it. Think of it it as evolution in action :).
The first case is much different; it describes a project whose author has fulfilled all his goals for it and wants to pass it on to keep it "live", as I see it. TortoiseCVS may just require the occasional fix and feature addition; it sounds like a stable program. I'll probably try it out, as I currently use WinCVS at work.
The abandonware problem (Score:4, Insightful)
I've been writing a graphics application which uses several open-source libraries. So far there's a cross-platform OpenGL interface, a GUI package for OpenGL, an XML input/output package, and a VRML->Web3D translator. All of them almost work. All are to some extent abandonware. I've put some work into fixing the GUI package, but don't have the time to dig into all the others.
And we're going to be in real trouble when (not if, when; read their financials) VA tanks and takes SourceForge down with it.
Well documented code may attract developers (Score:3, Insightful)
The class I TA for at MIT is 6.170: Lab in Software Engineering [mit.edu]. We force the students to learn how to write software using these documentation tools, in part to help them come up with better designs, but in part so that they can work more effectively as a team in their final project.
--Kurt
Re:rule number one (Score:3, Insightful)
Not in my experience. Perhaps your generalization holds up for others, though. But for me, the only way to keep my projects going is to walk away from them immediately. I am not a big developer. But for example, I wrote a few Applescripts for Outlook Express on the Macintosh. Including a well-loved script that restored password-protection to the app. I always released this code into the wild with text that stated the code was not only free, but that it had scratched my itch and others were invited to take over. All my Applescripts & Perl programs have since been completely taken over by others.
Perhaps in order to have a successful passing-of-the-baton, you need to disclaim ownership and encourage others to do as they wish. I see this as a flaw of mrgrumpy's approach to passing on his Java game, World. He wants to be the "grandfather" figure giving guidance and vision. He wants it to be GPL'd or similar. He wants to be sure the project won't gather dust. He needs too many assurances, and developers have a fear of commitment. When I use/patch code, I play with it out of curiosity and interest. So by encouraging freedom -- even freedom to fork code into new directions that I never intended -- my code always finds a new home or two.
Re:Come now, be honest (Score:3, Insightful)
Building on another post [slashdot.org] I made last week, I would rewrite your sentence as follows: "Open source is great, but it only works for projects interesting enough to generate interested contributors rather than someone's personal hobby code." Getting interested contributors doesn't require many eyes looking at the project, although it helps. It only really requires "luring" or "wooing" a couple like-minded people. Unfortunately, people tend to consolidate efforts and work on projects with the most critical mass. So a lone geek reinventing the wheel shouldn't be surprised to find that others want to put their efforts to the wheel that's already turning.
Honest? how bout pragmatic. (Score:4, Insightful)
Um... I'm trying to figure out just what you're saying...
Here we've got a CVS client for windows integrated with the windows explorer that somebody created because they thought WinCvs "wasn't good enough". Now, I don't know about you, but that sounds darned useful to me since I use CVS every day at work and get sick of using both explorer and WinCvs to do everything. Perhaps you know of some better projects which make this thing redundant? I sure don't.
Next, you seem to be implying that there are particular "more worthy" projects people should be working on. You supply a link to freenet and to mind.sourceforge.net whatever that is. Two pie in the sky projects that already have more developers then they'd ever warrant and likely will never amount to a hill of beans.
If you think Open Source is "public service" then you have fun with your "worthy" projects. Me, I'll be spending my time working on the tools that make my life easier. (and yes Margaret that includes whole operating systems for my extended family to use that I can actually get to work for them) Why will I give these tools away? So the next guy can work on something *more* useful, and maybe, just maybe, make my life easier in return.
hacker ethic n.
1. The belief that information-sharing is a powerful positive good, and that it is an ethical duty of hackers to share their expertise by writing open-source code and facilitating access to information and to computing resources wherever possible. (taken from the Jargon File [tuxedo.org])
Get some momentum going, then try it... (Score:3, Insightful)
I don't plan to get a new project leader any time soon, but I think I could without much trouble. The key is getting some active development going on the project, before asking someone to take it over. Consider managing the project for just one more release with a few new features, and soliciting for help. The new development activity will hopefully attract some contributors. From these, you should have one or two candidates for a new project leader.
-Erik