Yogi Yarns — On forking and plenipotentiaries

I ran the Jikes project for its first year. I was the king of the project.

I almost became a plenipotentiary. But forking came to my rescue.

Jikes was not just about the code. Our goal was to release some meaningful code in open-source form, under an open-source license, and to run the project under open-source rules with a URL that ended in “ibm.com.”

We wanted to show that IBM could both understand and play by the rules of the open-source world. Not just to talk the talk, but to walk the walk on the open-source road.

I was the undisputed king of that road for the first nine months. IBM Research was unable to allow the kind of outside-the-firewall access that would have been necessary to allow non-IBMers to make direct commits to the CVS source tree, since to do so would have required setting up a special server, and there weren’t resources on hand to do that.

I did the best I could. I acted as the agent of contributors, making all source changes in their name, and I made sure that each of them got proper credit for the work.

We had some success. For example, in August I suggested to Red Hat that they might to include Jikes in their next release, and they did so in September, making Jikes the first package written entirely by IBM under a license drafted by IBM and approved by the Open Source Initiative, the Jikes license, to be included in a major Linux distribution.

In late September I was approached by the folks who were setting up a new IBM web site. It was to be called developerWorks. It was modelled on IBM’s successful alphaWorks site that had been set up to demonstrate new technology from IBM. As I have written earlier, it was the release of Jikes on alphaWords in April 1997 that resulted in a very positive response that put Jikes on the map.

DeveloperWorks wanted to go beyond that, by providing articles and other materials. They also wanted to set an “open-source zone” and wanted Jikes to be part of the zone. They wanted Jikes to be run as an open-source project as part of developerWorks and offered to provide the necessary infrastructure.

This was very exciting news, as it meant we could finally run Jikes as a real open-source project, with outside committers being directly able to make changes.

I recruited a core team of experts in open-source and Java. I made it my goal to have the majority of that team not be IBM employees, to show that IBM was willing to trust others to have responsibility to run the project.

And then I ran into a roadblock.

What would I do if the core team hijacked the project, if they did something that was unacceptable?

There were several actions that would be unacceptable.

First, there was the possibility that the core team would decide to make changes to Jikes that would cause it to no longer conform to the Java specification.

Second, there was the possibility that the core team would take an action that I could not tolerate as an IBM employee. For example, taken to the extreme, suppose the core team decided both to distribute Jikes and pornography.

As an IBM employee I was then and now required to observe IBM’s Business Conduct Guidelines as a condition of employment, with the penalty of violating those guidelines being the loss of my job.

Although I didn’t really think the core team would take any of these actions, I felt that I had to address this issue as part of setting up the rules about how the project would be governed.

I struggled with this issue for a couple of weeks. I must have sent scores of e-mails to the core team as I dealt with possible solutions.

My goal was to have all project members have equal status, yet in order to make sure that the project’s governance would be acceptable to IBM, I had to come up with language that would solve the problems mentioned above.

The closest I got was to say that the project would be the responsibility of the core team, but therre had to be a “distinguished” core-team member from IBM who had the ultimate authority to veto a majority decision if the decision were deemed unacceptable.

I even started throwing around words like “supernumerary” and “plenipotentiary.” I probably spent some time reading Roberts Rules of Order.

And that’s when forking saved the day.

I sent a note to the core team saying the project would be run according to the open-source rules, but that if the team ever made a decision that Philippe and I could not tolerate, then we would fork the project and start a new effort. The core team could even continue using IBM facilities to run the project, but we would no longer be part of that effort.

That was the last note I had to send on this issue.

That is one of the powers of forking. It allows each project member the option of starting their own branch of the code if they are unhappy with the current project leadership, or if they want to take the project on a new path that is unacceptable to the current leadership.

Indeed, if is the fear of a fork that keeps everyone in line. Because if no one member has any special authority, then all authority must be earned by example and on merit, not by the exercise of an arbitrary power.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

  • Pages

  • December 2006
    M T W T F S S
  • RSS The Wayward Word Press

  • Recent Comments

    daveshields on SPITBOL for OSX is now av…
    Russ Urquhart on SPITBOL for OSX is now av…
    Sahana’s Respo… on A brief history of Sahana by S…
    Sahana’s Respo… on A brief history of Sahana by S…
    James Murray on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated

  • %d bloggers like this: