Transferring the Leadership of Open Source Projects?

Frabcus asks: "I founded an Open Source project TortoiseCVS, a Windows Explorer shell extension for using CVS, but now I'm looking to hand on project management to someone else. When I started out, I had an itch to scratch. We started using CVS at work and I didn't like the interface for WinCVS, so I made a better one. Now it's a year and a half later and TortoiseCVS does everything that I want it to, so I'd like to move on to other things and let someone else take it on. There have been over 20,000 downloads, so I have quite a large user base, but not many people are active in supplying patches. Do you guys have experience of handing on an Open Source project? How did you find someone who has similar goals that will fit in with the existing code?" The thing to do is to start asking around in development circles. The best starting place, of course, is among the existing user-base. For those of you who have transferred Open Source projects, how did you go about finding your successor?

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?

Comments

rule number one

[sam@caveman.org]

in general, if you leave the project, it will die. this is sad but true: unless there is someone other than you who has a substantial personal investment in the project in terms of blood, sweat, and tears, the project will fade away fairly quickly once people realise there is no committed leadership.

-sam

Re:rule number one

[puma_duh]

I disagree. The foundation of open-source projects is the team-work... that's what make a lot of them better than they closed-source counterparts. Most likely a lot of people helped him to get where he is. Finding a suitable sucessor among those who helped is just a matter of time and patience. And even without a centralized leadership the project may still grown, and the program can be improved.

Re:rule number one

[babbage]

I disagree. The ugly truth about open source is that, in spite of the grassroots image, every significant project has been primarily driven in a top down way. Think about the irony there. When you think closed source, you think Windows, Oracle, Photoshop, etc., all of which have big corporate names behind them, and thus their unseen legions of developers -- Microsoft, Oracle, Adobe. When you think open source you think Linux, Perl, Emacs, and most of them have the names of individuals associated with them -- Torvalds, Wall, Stallman.

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.

Re:rule number one

[Anthony Boyd]

if you leave the project, it will die

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.

When I have someone take over...

[nll8802]

I usually ask the most active bug reporters and patchers... One of them is usually quite willing to take over the project. I think if you didn't go to them first they would be a little upset since they feel they have already made quite a bit of contributions to the project.

Does it really need improvement?

[Eugene O'Neil]

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

[stoopidguy]

There is really no way of insuring that all of your own goals will be met. A new project leader means that they will put their ideas over yours, in 6 months you can take a look at the program and it will a total change from what you had/intended. But as the story suggests, send an email to the project's list and also post it on the page. Then just make sure the person you are handing it over to knows their stuff. If at all possible give it to someone who has been working on the project.

Come now, be honest

[sharkticon]

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

Re:Come now, be honest

[Anthony Boyd]

Open source is great, but it only works for projects interesting enough to generate "many eyes" rather than someone's personal hobby code.

Building on another post 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.

not necessarily

[indecision]

If the current release has useful features and is relatively stable, then there's no reason for users to stop using it, especially so in the open source case since if they have problems they may well be able to fix the issues themselves. This is true of a few things I use myself.

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

[dominion]

Since you started the project because you had an itch to scratch, then your best bet is to just announce that you are no longer maintaining the codebase, and that if anybody starts updating it, and needs to contact you, that they should.

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 Whore]

I realize that you have a personal investment of time, effort, etc. I know you'd love to make sure your "child" is in good hands. But the appropriate thing is to just drop it and walk away. If there is interest in continued development someone will take up the task.

easy

[Chundra]

Write a little message on your website saying something like:

"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

[alexhmit01]

If there aren't people interested, your best bet is to try to come up with a way to generate interest. Setup a set of web pages describing it, and submit it to the search engines. Place the code under the GPL or BSDL, and hope that people take an interest. Ask them to e-mail you, as you are looking for a maintainer.

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

Wanted: free labour

[czth]

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.

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

[Animats]

There's quite a bit of open-source abandonware. That's inevitable, but in many cases, the only open-source solution to some problem has been abandoned, or nearly abandoned.

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

[KurtSteinkraus]

Any developer who joins a project in progress has to learn how the parts of the program are laid out. It seems that the learning curve could be made less steep by documenting the program well. Comments are not the only helpful documentation; there are also object models and diagrams of all sorts, detailed specifications, use cases, coding conventions, etc.

The class I TA for at MIT is 6.170: Lab in Software Engineering. 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

Honest? how bout pragmatic.

[ebyrob]

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)

Get some momentum going, then try it...

[Seor Jojoba]

Similiar scenario--I have an old game that I am trying to breath new life into. I think it's working. It's not a glamorous project, but I had to take down my SourceForge job posting, after getting fifteen "sign-me-up" responses in two days. Right now there are five active coders besides me working on it. So it is possible, contrary to other posts here, to drum up some interest for an outdated game. It helps a lot to show people that you are organized and committed to getting things done. If you don't have the time and energy to play this role for a little while, you are probably in a Catch-22 situation. People will be more attracted to your project, the more committed you are to it.

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