Mik Kersten on Transparency

Posted by

symbianThis is a repost of Hayden Shaughnessy’s interview of Mik Kersten originally published on the Symbian Blog.

What are the prerequisites of a vibrant open source community? Mik Kersten’s open source career began with AspectJ, a project that made its mark with a core team of committers rather than community contributions. In contrast, the Eclipse Mylyn project Kersten created has seen over 800 bug and enhancement requests resolved by community patches, which represents 1/7th of the bugs resolved on the project. Mik, pictured [at right], is CEO at Tasktop Technologies. He attributes much of the success at Mylyn to the project’s transparency. I asked Mik to share some of the lessons he’s learned from his open source career and began by asking how we should understand transparency when of course there are commercial pressures and ingrained practices that predispose people to a more closed approach somewhere along the line on any project.

How do you manage that conflict and maintain an open management philosophy?

MIK: What’s essential to the transparency that enables community contributions is public and open discussion forums. It is common to have an organizational split between an open source project and one or more companies behind the project. One aspect of that split is the approach to making product plans, design discussions and decision making visible to the open source community. The level of transparency can determine how permeable a project is to community participation. For example, if Tasktop Technologies were to decide it wanted to introduce a new feature into Mylyn and attempted to do this in a non-transparent way, committing the code for the feature when nearly complete, we would forego the value of community participation and miss the opportunity for the community to harden, improve and extend that feature prior to its release.

How important is an open communications policy to that?

MIK: I believe that it is. It took me a long time to learn what that means, and I still frequently see companies having the goal of community participation, but not getting it right. Open development has to be transparent. Too many phone calls or private email threads on the side, and it becomes too hard for the community to follow what’s going on. Private communications will always have a role, but conversation that involve changing of a feature or API need to happen in the open and be captured for future review. That’s why Bugzilla has become such an effective vehicle and knowledge base for the Eclipse community.

What if that policy leads to conflict? You’re also an advocate of open conflict aren’t you?

MIK: There’s a range of conflicts we see happen. A great thing about open source development is the passions of technologists involved, especially when they are contributing in a volunteer capacity. Heated discussions arise regularly on any popular project, and are usually straightforward to resolve before they degenerate into flame wars. To handle the case when they do, we created guidelines to ensure that communications are respectful and professional. If there’s a technical conflict, committers can vote. Meritocracy is a key factor even with democratic voting, since participants on the project tend to value the opinion of those contributing most. More fundamental disagreements can arise, for example those over the trajectory of a project or governance model. In projects controlled by a single vendor, this is less likely since there is a top-down level of control. Vendor neutral projects and foundations are more likely to see this problem occur. A fundamental level of conflict of this sort has more potential for damaging the community, since a lack of convergence can result in a damaging fork for both the code and the community. I believe that it is important for the conflict happens in the open, since there can be separate and valid viewpoints within a project. Rather than having the project die the death of a thousand cuts by having people disagree continually due to the fundamental conflict not being identified, an open discussion will more quickly identify a more stable outcome, such as the need to split a growing project into sub-projects with independent leadership.

How do you regard the Symbian open management approach?

MIK: I haven’t yet engaged closely enough to have direct experience. But the approach of deploying and evolving Eclipse best practices and collaboration technologies like Bugzilla is a great step. Symbian faces challenges we at Eclipse do not. The size of the Symbian Foundation means it can handle engineering efforts independently of the community. In Eclipse, the community has to do all of the engineering work. This is a double-edge sword. We have experienced the problem of the “common good” of release engineering infrastructure not being provided by the Eclipse Foundation, and no single organization wanting to take on the entire burden. As a result, Eclipse has been slow in getting a satisfactory release engineering solution for projects, at a cost to all, especially smaller newcomers. But more recently we have had some substantial cross-vendor and community participation in making that happen. In contrast, Symbian Foundation probably has sufficient engineering resources to solve this problem with its own engineering staff, which in the case of release engineering is almost certainly a good idea, but this precedent could discourage participation in other common efforts, putting a disproportionate amount of burden on the foundation. In the end I believe that the best solution is to strike a clear and well communicated balance for the common good efforts that a foundation will support vs. those that will require community participation and coordination.

Is there anything in your experience that proves to be consistently a key turning point in an open ecosystem, a something that you look back on and say, that’s what really made this work?

MIK: Yes, the release of a new platform. Take the November 2001 open source release of Eclipse. We are still riding the wave of excitement and technology potential that generated. Mylyn’s adoption exploded with the 2006 release of its 1.0 APIs. Developers get very excited when they have a new framework to play with, so the platform just needs to make sure that the tools and rules of engagement encourage participation in order to let those first thousand patches bloom.

This entry was written by Haydn Shaughnessy, originally posted on the Symbian Blog January 14, 2010 at 12:01 PM