I’ve been strongly hinting in recent blog entries that I planned to do something concrete about the data-jail problems of present open-source hosting sites. Because I believe in underpromising and overperforming, I decided at the outset not to announce a project until I could not only show working code, but code with wide enough coverage to make it crystal-clear that the project goals are achievable with a relatively modest amount of effort.
That time has arrived. I am very pleased to announce ForgePlucker, a project aimed at developing project-state extractor software for backup, offline analysis, and (eventually) re-importation. The proof-of-concept code can extract complete issue-tracker state from Berlios, Gna!, or Savane — and issue trackers are probably the hardest part of the job. I expect extraction of repository histories and developer permissions tables to be easier. Extraction of mailing-list state is probably a bit trickier than either of those, but doable.
The code as it exists now is just 1100-odd lines of pure Python; it can dump tracker state in either JSON or an XML format. Notice that this is already a production-ready tool for, among other things, examining bug lists offline. One of the goals in the project plan is: useful tools at every step of the way. This is not going to be a project where the developers toil in obscurity for years until releasing Epic Code That Changes Everything; the project plan lays out smaller deliverables that can be used to build cooperation with forge-system designers and other people interested in some of the data-transport problems associated with forges.
Accordingly, I’ve actually put as much effort into documentation than I have into code – there’s a project plan, a HOWTO on writing forge handler classes, and even a draft ontology of forge state we can use to translate among the data models of different forges.
Yes, I’m looking for co-developers. What the project especially needs is people interested in taking responsibility for developing and maintaining the handler classes associated with different forge types. Presently, I own the Savane and Berlios handlers; I’d like to give those away so I can concentrate on the framework code, and I hope to recruit owners for SourceForge, GForge/FusionForge, Launchpad, and Trac.
There’s lots of interesting work to be done here. Much of it will be code, some of it will be standards and documentation. Relevant skills and technologies include Python, JSON, RDF, HTTP forms, web-scraping, test-driven development. As always, being highly motivated to address the problem is more important than knowing any specific toolset at the outset. I expect this project to be genuine fun; it breaks naturally into small substeps on which you get rapid feedback at each stage, and testing for correctness will be relatively easy.
Once we field a forgeplucker that can pull complete project state off a suitably wide variety of forges, it will be time to think about tackling the re-import problem. We may solve that by bolting importers onto existing forge systems one by one, or by launching a forge-development project that builds on our extractor tools. Another direction we might go in is supporting scripted interaction with these systems. At every stage, useful tools!
To participate, get an account on Gna! and apply to join ForgePlucker. You can also examine the source-code repository and llist of open tasks. You will probably want to join the mailing list. I’m planning to set up an IRC channel as well.
(Yes, I’d rather have used a distributed VCS; I did my proof-of concept in Mercurial. But Subversion is the best we can do on Gna!, where I have the advantage of being a site administrator.)