Over the past few months I've been quietly tracking our upstream and downstream interactions. The motivation for this has been my experience with the KDE 4 series, in which we have both been on more people's radar (when was the last time NVidia mentioned KDE 3 in a driver release?) and seen more trainwrecks both up- and down-stream from us.
In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.
Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.
Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.
The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.
This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.
Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.
While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.
In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)
Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.
I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.
I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.