On the Cutting Edge
Considering the fundamental structural problem of the free software movement
There is a fundamental structural problem in the open source movement. Within a given project, things generally find a way to get done, but when a problem lies between two projects (be they peers, one dependent on the other, whatever) then things often remain unresolved.... This is actually the cutting edge area in the free software movement at the moment - trying to find a common ground for not just projects but constellations of projects and above them distros to collaborate.
Whilst contribution is the barrier to entry (ie, my talk last year, and this year's conference theme), there is a bigger issue: the overall continued viability and success of the open source movement. And that will take us finding ways to cross the bridges between projects.
The question has a number of aspects. Although any problem involving humans interacting is ultimately a social one, we are nevertheless face a situation where our tools are holding us back. But don't worry: in the grand tradition of free software gurus, I shall not let so-called "reality" get in my way as I describe the future Utopia that awaits us.
Why there are there 80,000 unfinished one man show projects on SourceForge? The "not-invented-here" syndrome means that so many of us keep re-inventing the wheel; and that's so often because we think its easier for us to start work on something new than to contribute to an existing project. We all know there are lots of reasons for this, but a big part of the truth is that contributing is hard. That's what we have to change.
So this talk will look at what getting in the way of projects co-operating with each other, and take a wild romp through the amazing and vibrant activity taking place in the area of tools to support us. The present state of affairs is not encouraging: there is a proliferation of incompatible project hosting and bug tracking systems. Inefficient communications mediums that help us to rant at each other but don't help us to reach decisions. The contentious struggle to develop a next generation source revision control system rages on. Even the hallowed release cycle of GNOME is up for examination: is it developing quality software or preventing people from easily contributing?
The times, they are a changing, however. Of particular interest is the version control debate. Working closely with the proponents of a number of the latest entries in distributed version control land, I'm going to talk about why this has been such a ripe area of activity, but focus on something that one of the bzr developers just noted to me: "We spend so much time chasing the Distributed Version Control System grail because that's what everyone thinks we should be doing - but it's not clear whether that's actually the problem that needs addressing: when someone approaches me and says 'but I just want to share my branch' are we really helping them?"
Source code is just part of the equation; another huge factor is getting that code to build. The solution here has long been automake + configure + Make + libtool but the they way they approach the problem has long been primitive. There has been some dramatically new developments lately in this area focused on helping code from different projects work together. It's going to take all of us to get it to succeed, but if we can cross the divide, then we will have made a major step towards working together.
Last year I said the barrier to entry is contribution. This year we are going to talk about the criterion for success: ensuring that the barrier to other people contributing to your project is low. If we can remove the impediments to collaboration then together we can really make free and open source software the road that into the future. Apotheosis rising.