Earlier this week I did a keynote at [All Things Open](https://allthingsopen.org/). While the topic covered the opportunity of us building effective community collaboration and speeding up the development of Open Source and innovation, I also touched on some of the challenges.

One of these challenges is *sustainability*. There are too many great Open Source projects out there that are dead.

My view, although some may consider it rather romantic, is that there is a good maintainer out there for the vast majority of these projects, but the project and the new maintainer just haven’t met yet. So, this got me thinking…I wonder if this theory is actually true, and if it is, how do we connect these people and projects together?

While on the flight home I started thinking of what this could look like. I then had an idea of how this could work and I have written a little code to play with it. This is almost certainly the wrong solution to this problem, but I figured it could be an interesting start to a wider discussion for how we solve the issue of dead projects.

# The Idea

The basic crux of my idea is that we provide a simple way for projects to indicate that a project needs a new maintainer. The easiest way to do this is to add a file into the source tree of the project.

This file is an `.adopt` file which basically includes some details about the project and indicates if it is currently maintained:

For example:

[Project]
maintained = no
name = Jokosher
description = An audio multitracker built for the GNOME desktop.
category = Audio
repo = https://www.github.com/the-project
discussion = https://mymailinglist.com/jokosher
languages = Python

[Contact]
name = Bob Smith
email = [email protected]

Now, this is a crude method of specifying the main bits of a project and much of this format will need tuning (e.g. we could pull out languages and frameworks out into a new block). You get the drift though: this is metadata about a project that also indicates (a) whether it is maintained, (b) what the key resources are for someone to get a good feel for the project, and (c) who the contact would be to help a new potential maintainer come in.

With this file available in the source tree, it should be publically available (e.g. the raw file on GitHub). A link to this file would then be pasted into a web service that adds it to a queue.

This queue is essentially a big list of `.adopt` files from around the web. A script then inspects each of these `.adopt` files and parses the data out into a database.

This database is then used to make this list of unmaintained projects searchable in some way. For example, you could search by category or programming languages. While `maintained` continues to be set to `no` the project will remain on the list.

When a suitable maintainer steps up and the project is alive again, all the maintainer needs to do is set this `maintained` line to `yes`. On the next scan of the queue, that particular `.adopt` file will be identified as now maintained and it will be removed, thus not appearing in the database.

# A First Step

To provide a sense of how this could work I threw some Python together at [https://github.com/jonobacon/adopt-a-project](https://github.com/jonobacon/adopt-a-project).

It is built using [CherryPy](https://www.cherrypy.org/) to keep it simple. I wanted to avoid a full-fledged Django-type framework until the core premise of how this works is fleshed out. A caveat here: this is a really quick, thrown-together prototype designed to encourage some discussion and ideation.

It works like this:

* Run `website.py` to spin up a local webserver on `127.0.0.1:8080` that will display the empty queue. You can then add some remotely or locally hosted `.adopt` files by clicking the button at the top of the page. I have included three examples on GitHub [1](https://raw.githubusercontent.com/jonobacon/adopt-a-project/master/exampleadopts/example1.adopt) [2](https://raw.githubusercontent.com/jonobacon/adopt-a-project/master/exampleadopts/example2.adopt) [3](https://raw.githubusercontent.com/jonobacon/adopt-a-project/master/exampleadopts/example3.adopt). These are added to `queue.list`.
* You then run the `adopt-queue.py` that will scan the queue and create a sqllite3 database with the data.
* The website then includes a really simple and crude list of projects and the links to the relevant resources (e.g. code, discussion).

Now, as you can tell, I have only spent a few hours knocking this together and there are many things missing. For example:

* It doesn’t include the ability to search for projects or search by language.
* The schema is a first cut and needs a lot of care and attention.
* The UI is very simplistic.
* There is barely any error-checking.

# Topics For Discussion

So, this is a start. I think there are a lot of interesting topics for discussion here though:

* Is this core concept a good idea? There is a reasonable likelihood it isn’t, but that is the goal of all of this…let’s discuss it. 🙂
* If it is the core of a good idea, how can the overall approach be improved and refined?
* What kind of fields should be in an `.adopt` file? How do we include the most important pieces of information but also keep this a low barrier for entry for projects.
* What should be the hand-off to encourage someone to explore and ultimately maintain a project? A list of dead projects is one thing but there could be instructions, guides, and other material to help people get a sense of how they maintain a project.
* Maintaining a project is a great way for students to build strong skills and develop a resume – could this be a carrot and stick for encouraging people to revive dead projects?
* What kind of metrics would need to be tracked in this work?

To keep things simple and consistent I would like to encourage this discussion over on the [project’s issue tracker](https://github.com/jonobacon/adopt-a-project/issues). Share your comments, thoughts, and methods of improvement there.

Thanks!