New Page – One Page

If you look at the top of this page you will find a new entry, “One Page,” between “License” and “Posts.”

“One Page” is a single page with all the posts combined into one giant page, in the order in which the posts were written.

This lets you use your browser’s “search” function as an alternative to WordPress “search.”

It also lets you read the posts in the order in which they were written, thus providing an alternative to viewing them in the reverse order that is commonly used, and so you can read them without the “Future is Now” effect.

I did a little counting using the “wc” utility. So far the page has about 170 posts. They comprise about 7600 lines, 125000 words, and 775000 characters.

Almost all the posts were written since mid-September, starting about 80 days ago, so I’ve been averaging about 1500 words per day. (Yikes! Time to get a life.)

The total views to date is quite close to the number of lines. Go figure.

With Jikes we averaged about one bug report for each thousand downloads. The blog is now averaging about one view for each 100 characters. I wonder if that will hold. Is it quantity, or quality, that counts?

The blog is now averaging over 100 views/day, about one view for each 15 words.

I haven’t recorded the dates of posting, but if you hover your mouse over the URL at the start of each post you can find the date, as WordPress includes it in the generated name for each post.

I’ll try to keep “One Page” up to date going forward.

Yogi Yarns — If you come to a fork in the road, pick it up

Yogi Berra and Emily Post are out on a stroll. Emily sees a metal object blocking their path. She asks Yogi what to do. Yogi says, “If you come to a fork in the road, pick it up.” They continue their journey.

That’s really all you have to know about open-source and forking.

If you don’t like the way a project is being run, you just say, “You folks are toast. Stick a fork in your project. It’s done. I’m going to pick my up marbles — and your code — and go play with it myself.”

It’s the fear of that possibility that keeps everyone on their toes. You have to pick yourself up each and every day, doing your best to deal with all problems and controversies in the fairest possible way, because if someone else thinks they can do a better job there is nothing you can do to stop them.

Forking isn’t “bad.” It’s not “evil.”

Forking is wonderful. It’s the great pick-me-up of open-source, the flywheel that keeps everyone on the same path. It is a source of strength, not a sign of weakness.

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.

Why blog? If you don’t, who will?

Glyn Moody, in his post Who are the Hacker Bloggers?, begins:

If you look at the font of all wisdom – no, I don’t mean Wikipedia, but Amazon – you will find stacks of books with titles like The Corporate Blogging Book, Blogging for Business, Blog Marketing and the rest. Whatever the title, the basic message is the same: if you’re in business, you’ve got to be blogging. Because if you aren’t, you’re not “having the conversation” with your customers, which means, in turn, that you’re not getting your message out or valuable comments back.

and goes on to note that few recognized, well-known programmers, blog.

I have done some investigation. My first guess was the most hackers don’t blog because they are too busy writing code.

I also think there may a lag in recognizing the advent of several new technologies in the last few years.

Traditionally, open-source development has had as its core mail lists and also the “source tree” in the form of CVS, and more recently, Subversion. Open-source development at a serious level, then and now, takes place in this context.

At least that was the world as I saw it back in 1999 during the year I ran the Jikes project.

When I started blogging a few months back, I did so in part to explore the utility of the new technologies that have become more widespread since 1999:

• blogs, for example, WordPress
• wikis, for example, MoinMoin and Wikipedia
• content management systems, for example Drupal

Indeed, the 150+ posts you can find here were written mainly to explore the utility of blogs.

But beyond technology, my experience suggests a larger role, one that I find increasingly important, especially in that I am blogger who writes both as an individual and as an IBMer.

In the Jikes days I worked for IBM Research. I then spent a few years at IBM’s Software Group (SWG), and am now part of IBM’s Systems and Technology Group (STG), in the group known as the Linux Technology Center (LTC).

I have followed up on Glyn’s query, and here is the situation as I understand it.

There are a few URL’s that should be included here, and I will dig them up later.

In brief, I estimate that fewer than 300 IBMers blog outside the IBM firewall in a serious fashion, and the number is probably less than 100. Given that IBM has over 300,000 employees, that means that fewer than one in a thousand IBMers blog outside the firewall.

This in spite of the encouragement of IBM’s management that IBMers are free to blog outside the firewall.

One of my LTC colleagues recently put together a list of LTC bloggers, distinguishing “personal” from “professional” blogs. Personal bloggers make minor mention of their life as an IBMer, professional bloggers make it part of their blogging. I count myself as a professional blogger.

Only three LTC members are professional bloggers. I am one of them.

Outside of the LTC I know of only two other IBMers who are known as open-source developers who blog on a regular basis: Ken Coar (occasionally) and Samy Ruby (regularly).

I find this troubling.

My own blogging began in my efforts outside my day-to-day work, as part of my volunteer efforts to encourage those with open-source skills to volunteer to use their skills to make the world a better place, but I think it also important that I write when I can just as an IBMer, to offer my own perspective.

While IBM supports blogging inside the firewall, I think this is not serious blogging.

To blog inside the firewall is to be the minister speaking to the choir, or a choir member praising the minister.

To blog outside the firewall is to engage with the real world, to speak with customers, colleagues, adversaries, and observers …. on their terms, on the common turf.

That’s what counts — the real world, not the inside-the-firewall world.

Because if you won’t speak for your world, to the world, then who will?

Risky, yes. But why shy away from the risk. Better to talk with others than to hide behind the firewall.

I also think that those IBMers in the “older” generation, the ones who have been with IBM for more than five years, have an obligation to reach out, and that the best way to reach fellow IBMers is not within the firewall, but outside of it.

At least that’s my view.

If we don’t blog, who will?