So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)
It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.
Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)
More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.
It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.
Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.
I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.
Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.
Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.
It seems to be working out well, but what happened differently here?
People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.
It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.
This all seems common sense, doesn't it?
Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.
So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.
So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.
What we are (or at least I am) missing are sure-fire ways to replicate these results when:
- We don't all know each other, or know each other very well
- We aren't in constant, regular communication with each other
- We rely on each other for different pieces of the puzzle
- We have independent bodies setting each group's agenda/roadmap
- The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".
And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.