I’ve written before about the problems with today’s software-forge sites – how they’re craptacular piles of PHP driving direct SQL queries with almost zero scriptability that become data jails for open-source projects. I’ve hinted that I think there’s a potential solution based on Roundup, a brilliantly simple and powerful message queue manager disguised as a mere issue tracker.
Two years ago I started an effort to address the data jail called “forgeplucker”. This project has since stalled, partly due to problems (irony alert!) at the hosting site I put it on, and partly because there was a basic problem with it that I acknowledged at the time: it doesn’t do a lot of good to have working project state extractors if none of the forges are writing injectors. Nobody has stepped up to do that, leaving forgeplucker a useful learning experience but something of a dead end in itself.
One of my regulars recently predicted that I would do something dramatic about the forge problem within two years. That prediction was correct; in fact, I’ve already begun the preparation work.
However, I’m not announcing a new forge. Yet. The path I’m pursuing is sneakier and more interesting than that. It relies on the fact that there is a mature, stable, and field-tested implementation of Roundup already in existence in fact, the Python development group uses it as their issue tracker.
Roundup has a number of interesting properties. One is that every capability in it can be scripted via a mail robot or an XML-RPC interface. Another is that the message queues are accessible through either a web-forum-like interface or email – content is separated from presentation. Most importantly, it already works – it’s got ten years of history, tested code, happy users, and a development community.
Some weeks ago I joined the Roundup development list, explaining my interest in using it as a platform for a future forge system. As a first contribution I explained about reposurgeon and offered to lift the project repo from Subversion to a DVCS; the project founder accepted this offer, and I have done the job. As a nice side effect, reposurgeon grew a nice list of new capabilities in the process, essentially everything in releases 1.3 to 1.10.
So now I’m a dev on the Roundup project, in fact an administrator (which was needed so I could do the repo manipulations). My plan is to add certain new primitive capabilities to Roundup. Each of these capabilities is orthogonal to the others and can be functionally justified on its own terms. Here are the big ones:
Extract/inject: Extract will dump the state of a Roundup instance as a big hunk of (yes) JSON; inject will take that JSON and use it to populate a live Roundup instance. The standalone justification for this is that it can be used for tracker state backups.
Namespaces: Presently, each Roundup instance hosts just one tracker (message queue). It should be possible for a Roundup instance to host multiple named message queues. The standalone justification for this is…itself.
Network-wide identities: Presently, Roundup identities are login-name/password pairs. It should move to being based on email addresses coupled with ssh and PGP keys – network-wide credentials the way DVCSes handle identity. The standalone justification for this is to reduce the number of credentials Roundup users need to manage.
A repository-management class. Roundup has a role-based permissions system. A primitive object type could be added to Roundup that would use that permissions system to control access to a DVCS repository.
There’s no mystery intended about where this is going. If all these features were successfully added to Roundup, it would have all the capabilities of a forge. The message queues would span the functions of issue trackers and mailing lists. The “forge” part would be some management logic for associating a group of message-queue namespaces and repository objects with a project name and giving them all one set of access permissions.
But I don’t want or need to promise a forge yet. The plan is to add these primitive orthogonal features to Roundup. At each stage they’ll get actual testing in real deployments. Rather than trying to design a forge now, what I aim to do is push these capabilities into Roundup until one of two things happens:
1. I hit a wall. The underlying architecture isn’t robust enough to carry these features. (I regard this as possible but very unlikely.) If this happens, I have to think up another approach.
2. All these features are successfully integrated. Then a forge could be written as a thin layer over the enhanced Roundup – and, functionally speaking, it would nuke every existing forge from orbit. Just the complete XML-RPC scriptability alone would make it a category-killer.
I have not started coding yet, mainly because I have a writing project I’ve promised I’d finish before I dive into this. But the existence of Roundup will save immense amounts of coding and community-building. The project has a ten-year history; I estimate it would take four to five person-years to duplicate the capabilities it already has in a stable and tested codebase.
With Roundup to start from, on the other hand, I think we could get to a world-beating platform for forge-building in nine months to a year. I’m going to do extract/inject as my first bit, building on experience with ForgePlucker. One of my blog regulars, Susan Stewart aka HedgeMage, has already joined the Roundup project with the intention of doing the network-identity piece. We’d love to have somebody working on implementing namespaces; all these things should be doable in parallel.
If you want to help, please join the roundup-devel mailing list, introduce yourself, and explain which part you want to work on.