abm (14) amp (18) ascape (6) biomed (6) business (22) butterflyzer (9) dharma (12) eclipse (62) emf (7) graphics (10) ip (8) java (35) life (5) osx (13) science (13) web (6) xpand (5)

Thursday, May 5, 2011

The Eclipse Community and Victory over Conflict

I just read Andrew Bayer's really nice post. I tried to respond there, but naturally I got too verbose. Someone needs to come up with a good solution to this problem of blog posts and comments and half-blog posts half-comments that end up spread all over the place. And make a hundred million dollars on it. (And no, Google Wave wasn't it.)

Andrew said: "It's a natural human instinct to want to be the winner when there's a conflict, but no reunion is going to be possible if one side insists on a PR victory over the other." That's really really true. It is always necessary for people to give up ground. But I think that's what we need to do and I'm going to talk about that in a followup post.

As I mentioned in my earlier post on the subject, the thing I really appreciated about Jenkins is the creative way that they found to step outside of the conflict altogether. I mean maybe that wasn't entirely the intent, but it felt like someone had read The Art of War. Which is just as much about peace in a non-obvious way. I also appreciate what Andrew had to say about sometimes things just going there own way.

But if Andrew and the rest of the Jenkins community are interested in reaching out or engaging in any way, I know that there are many people in the Eclipse community that would be happy, actually eager, to help. I think very few people really want to see this as an us-vs-them thing.

But how to deal with it? I'm going to say something unorthodox. I don't think you really make things better by talking about them and negotiating and making peace offerings. So often that just makes things worse. People's positions just get hardened further, and we create more history to overcome and more confusion. We see that in the Middle East and Korea and that is with all kinds of experts helping to "fix" things. And you certainly see that in this case, where people are still arguing about posts that someone made six months ago.

So from what I've seen some kind of meeting in the DMZ and coming up with a reconciliation plan often doesn't work out that well. Instead, I think it works better when people get together in an organic way or just get fed up with the hassle of arguing all of the time. This isn't a top-down leadership process, it's totally bottom-up, people talking to people. In this approach, disputes aren't overcome, they simply become irrelevant. One day you just wake up and think "what the hell was all that about anyway?"

So to get there doesn't really require Oracle or Jenkins to make some kind of specific gesture. And actually, come to think of it, what's Oracle? Oracle doesn't really exist. (And neither does Jenkins for that matter.) It's just a bunch of people, contracts, equipment and so on that it's convenient to pretend is a single entity. So let me tell you that the great thing about Eclipse is that it has a sneaky, even subversive, way of separating out people from corporations. (Don't tell the suits.) It is about building trust in and relationships with other developers. So practically speaking here are some paths that Jenkins could follow. They aren't mutually exclusive!

1. Continue to build the great community and technology that Jenkins now has.

2. Indicate that you are an "interested party" for the Hudson proposal. Perhaps request that Kohsuke be made a project co-lead. All communications about projects at this stage are supposed to be public. But note that part of the Eclipse Proposal process is a loose mandate to projects to make an effort to bring in lot's of different efforts. You can't force that process but if everyone is acting in good faith it could work out nicely. Of course there are lots of reasons that might not work for you.

3. You could make a proposal for a Jenkins project. Again, that may be something you just don't want to do, for technical, business of political reasons. But creating the proposal isn't difficult and again plenty of people to help. I'm sue the proposal would be treated equally, and presumably you wouldn't have to do as much heavy lifting for the IP issues. Of course, you might be encouraged to try to combine projects, perhaps under an overall CI umbrella. I'm just speculating here, not trying to create extra headaches for the foundation.

To some of Andrew's specific concerns. "since the split to corporate-sponsored work as compared to the more independent developer-driven Jenkins". Really, the one thing I'd say about Eclipse governance is that it is developer driven. There are some very important caveats about that, but it is really true in the day to day work.

Now to whether Hudson is Java driven or not.. It really doesn't matter. As project contributors even the project leads can't tell you *what* to work on. If you've made a commitment on something of course it would be assumed that you'd see that through. But it really is a vote with your feet/code thing. If a group of folks wants to work on something the project lead can't stop them. Worst case the lead could refuse to include it, but they'd have to have a really strong justification for it. A bigger issue is of course when there are conflicting design agendas. I think that that is the thing to thing through carefully. Are there any insurmountable design differences, i.e. that couldn't be solved by abstraction. The second point is that Eclipse isn't really as Java driven as you might think. Besides of course supporting all kinds of different languages, there are a number of efforts based on other platforms, notably Orion.

Anyway, some thoughts, hope they are helpful.

I can't help but speak personally for a minute about my own spiritual tradition and why I'd care about this, seeing as it isn't something that really affects me directly. As a Buddhist -- whatever that means -- I don't see conflict as a problem, but as a precious opportunity. It's not something to avoid or even to try to fix, but a part of the path. Conflict is an opportunity to bring our compassion and mindfulness -- however meager -- from the realm of the theoretical into activity that can actually benefit people. All of us -- and it doesn't matter what we call our own approach to things -- can benefit from seeing conflict this way. When people disagree with us or cause us harm, our habit is to push back. When we decide not to go with those habits but instead do something completely unexpected -- that's when we start having fun!

"Victory over Conflict" is another way to say "Victory over War" which is the slogan of the Dorje Kasung. Members of that organization have written an excellent translation of the Art of War.

4 comments:

  1. One of the things to remember, is that Jenkins has a completely different release process than any eclipse project. Jenkins releases a build every week. They don't label it as milestone, beta, release, or anything else. The Eclipse Development Process has a very special meaning for calling something a release. The release means it has gone through the entire Release Ware process of IP Logs, promoted release review, etc. I can't imagine it being able to work like this at Eclipse. If they called things Milestones, or whatever it could work, but they could never call it a release.

    This is a fundamental difference between Hudson and Jenkins at this point, is the development process they follow. Hudson's corporate backers wanted a slower release schedule, Jenkin's developers prefer a faster weekly release schedule.

    Personally, I prefer the Jenkin's schedule, but trying to bring that schedule into the eclipse development process would be overly painful.

    ReplyDelete
  2. I'm glad you brought that up David, because it is the one thing that Andrew talked about that I feel like I can shed some light on. First, note that a release is nothing more than something to call a specific version. Certainly there is a formal process for Eclipse "Releases". That means something and it is pretty heavyweight. But Eclipse also has a very rich process for managing all of the other cases that is I think a perfect fit for the case you describe. If you look at the download sites for Eclipse projects and the SDK build itself, we actually have four different stages of builds - nightly, integration, milestone and stable (release). All of our build systems are set up to handle this. (Oh yeah, they run on Hudson..) But you just change a single different parameter and voila, you're building the milestone or the release. With Git support it would be straightforward (hah!) to handle maintenance branches as well.

    So people that like the Jenkins model can grab a release weekly if they want, and people that want the "blessed" release can wait until the organization gods decree a particular version thus. Perfect, eh?

    ReplyDelete
  3. The point being is that Jenkins only has one type of release and that is a weekly release. Why force additional process on the project when it seems to work well with out the additional process.

    And if they came to eclipse, they couldn't use the term release unless it went through the official release ware process at eclipse. It may seem like a minor thing, but it is something to keep in mind.

    ReplyDelete
  4. No it doesn't sound minor at all. Those kind of things have a lot to do with the whole culture / feeling of a project. And you're right about the release terminology too. There would at best have to be some creative thinking about how to accommodate both approaches in some way, especially if the Jenkins team wants very high release quality every week. The typical Eclipse project approach is to treat the nightlies as bleeding edge, though the interims are often quite stable.

    ReplyDelete

Popular Posts

Recent Tweets

    follow me on Twitter