Thursday, January 04, 2007

Abandoned Projects, Bus Proofing, and a Draft Directive

I'm glad the people behind RubyForge have come out with a formal plan for handling 'abandoned' projects. I don't like the decision they made, but it's their's to make, so I guess I can't argue. Instead, I'd like to make sure I 'bus proof' my projects — if I get hit by a bus (or otherwise drop off the 'Net),

To me, running a project is both an opportunity and a responsibility. In starting several projects, I've taken on an obligation to the community, and if I just abandon a project I'm not fulfilling that obligation. (To me, while "Free as in speech" is more important than "Free as in beer", "Free as in puppies" is pretty important too.)

I'd like it to be clear that I want my project taken over and maintained. The immediate parallel that comes to mind is a Living Will. Here's my first cut at it:

If someone wants to take over this project, they should send email to me, the project administrator. If there is no response within one month, they should send email explaining the situation and asking for me to respond to the ruby-talk list. If there is no response from the project admin within one month I, the project administrator, direct the RubyForge administrators to add the requester to the project with full administrative privilege. If I do do not respond within a further month, the requester may then remove any administrative privileges for this project from my account.

After a bit of discussion around this idea, I plan on attaching a directive like this to all of my projects on RubyForge, and encourage everyone else to do the same. (Tom Copeland suggested that I put it in the Doc Manager of the project.)

I don't think this is just a problem (and solution) for the Ruby Community there are a lot of projects on Sourceforge, Savannah, etc. I'd love to hear comments from non-Rubyists too. I hope that given enough eyes and minds, we can come up with a standard directive (or maybe a couple of them) that can solve this problem.

5 comments:

Anonymous said...

Wouldn't you want to transfer the full copyright, too?

Best might be to assign a non-exclusive copyright for your code now to Rubyforge itself, which they can non-exclusively transfer to the new owner at their disgression. Otherwise you have permamently locked the license for a project you no longer care about. Of course this also means you have to trust Rubyforge to not act contrary to your wishes.

I guess this is the formal plan you refer to?

Anonymous said...

Discretion, even.

gnupate said...

Evan,
yes, that is the formal plan I'm referring to.

Transferring non-exclusive copyright might be a good idea. I've asked a couple of lawyers to look at this too, so I'm hoping they'll have some idea of how to improve the directive.

Anonymous said...

I support pate's idea here.

I have run into several projects that look useful. Then I run into issues and email for support/help and they tell me that the project has been inactive for years and that it isn't maintained. Sometimes the project is so out of date that it doesn't even work anymore. For example pdf2svg seemed like a great tool to use, but the Perl modules that it depended on were since upgraded/changed and now it doesn't work anymore.

Anonymous said...

RubyForge's decision to simply fork projects is the right one for them. They're a software distribution repository, and don't have the resources to manage intellectual property issues for all the projects they host.

That said, you're on to something important here. And it's not just a problem for Ruby, it's a general problem with open source projects. (Or perhaps a general advantage of open source projects, since you wouldn't even have access to the source code to take over if it was a proprietary project.)

The best structure I've seen for this is the one used by the Apache Software Foundation. They take a contributor license agreement from every contributor with commit access. If a particular project owner disappears, the ASF can assign new maintainers. The license agreement doesn't specify a particular open source license that Apache has to use to distribute the contributed code, so the ASF even has the right to change the license the project is distributed under (though it's unlikely that they would). The ASF is aiming for larger projects with multiple contributors, but the same idea could extend to smaller projects with one developer.

Because Ruby doesn't have a foundation backing it, there isn't an obvious entity to take ownership of these license agreements. Many of the Sourceforge projects are in the same situation. You might look at Software in the Public Interest as a generic legal entity to hold intellectual property.

In the absence of any umbrella legal entity, it's unlikely that a copyright transfer based on not responding to email for two months could be considered legally binding. In which case, the living will wouldn't have any more legal significance than a simple fork. It would grant the developer who forks it the right to keep using the same name, but there isn't really any legal obstacle to using the same name anyway (just a practical one because of the way RubyForge project administration works).

One problem you'll eventually face is what happens when the original creator of the project comes back?