Daily Archives: December 9, 2007

On OpenDS: Time for Sun to make a call

[Other posts on this topic: previous next]

The latest contretemps in the open-source community is “L’Affair OpenDS,” the tale of Sun’s adventures — and misadventures — in its handling of the OpenDS project. According to the OpenDS project’s web site:

OpenDS is an open source community project building a free and comprehensive next generation directory service.

I have already written a few posts about this matter, and take this occasion to add another, for I think it provides a good case study of the issue of open-source project governance.

Here are my prior posts, in the order written:

OpenDS: On Being Bitten By The Hand That Once Fed You

xo-laptop xo-python On Sun and the Tragedy of Java

OpenDS Exegesis Ecclesiastes 5:13

This post is the post I mentioned that I would write in the last post above, the one with the quote from Ecclesiastes, “The Preacher, the son of David, king in Jerusalem.”

By way of background, I have written over six hundred blog posts in the last year or so as a volunteer, on my own time and on my own dime, seeking to promote to promote use of open-source and other open technologies to assist our educators and librarians in their vital mission.

I have had extensive experience in starting and running open-source projects, and advising others on how they should do it. I also had misfortune to be a member of an open-source project, Stellation, that proved to be a miserable failure. I have direct, personal experience of both the good and the bad, what works and what doesn’t.

Companies can engage in open-source activities in many ways: by using open-source in their products, or by reselling OEM products that contain open-source code, by authorizing empoyees to participate in open-source projects, and so forth.

The issue here is what is the best, most effective way for a company to release code it has written in open-source form, with the intent of attracting users and developers who will use the code, test it, report bugs, enhance it, document it, and so forth. Moreover, all this only is of value if an enduring community can be built — the goal has to be not just to build a community, but to build a self-sustaining one.

Most of what I have learned about doing open-source in the almost ten years I have been engaged in open-source activities can be summarized in the following sentence that can be found in my post:
Can you explain open-source in one sentence?:

You must be completely open — holding nothing back — for if you hold anything back then you will lose trust, and trust once lost is almost impossible to regain.

This observation follows from a lesson I learned both as an open-source developer, and in the years I spent at IBM Research when I tried to get code I had written into IBM products:

To gain any meaningful control in the long run, at one point you have to give up all the control you then have.

It took me about ten years to make these observations, as I spent a lot of time experiencing directly what happens when they are not followed.

For example, I left IBM Research five years ago to work for IBM’s Software Group as part of the small team that managed IBM’s day-to-day open-source activities. I still do the same work, though the team is now bigger and I now work for IBM’s Systems and Technology Division, where I am a member of the Linux Technology Center (LTC).

Fran Allen hosted a reception at Research shortly before I left. One of the nicest compliments I have ever received was her mentioning in a speech that I had written one of the best memos she had even read during her IBM career. I wrote it near the end of the almost five years I spent working on IBM’s product compilers, and the net of it was my observation that the key step in successful technology transfer was that our Research Team had to finally let go of the reins. The code we had developed at IBM Research in Hawthorne, New York, now belonged to the product team in IBM’s Toronto and Santa Teresa Labs. What once was ours was now theirs; we were no longer the authors and editors, but assistants; not “big boys” but humble drones.

I have been down this road several times, and I expect that any programmer who has worked on product-level code, be it in the halls of Redmond, or the halls of Oracle, or the halls of IBM, can relate numerous instances of all the bad things that happen when people either refuse to let go of the reins, or are so obsessed with their own skill and power that they don’t even know there is control to be given up.

When a company seeks to start an open-source project, the first question to be answered is “Make or Buy?” Should you start a new project on your own, or join an existing community.

I have written many posts on the “Make/Buy” question. Here is a list of some of them:

Make or Buy?

Make my day

Make or buy? Home, sweet home

Make or buy? Home, sweet home — on the web

You make the call

As for Make versus Buy, my experience has been, and my advice to any company that seeks to start an open-source project, is that it is always better to buy into an existing community instead of trying to build your own.

It has also been my experience that if you have any questions about how to do open-source, or how to manage the people who do it, or how to train the people who don’t yet do it, the single best source of guidance is theApache Software Founation. The Apache http server one of the foundations of the internet. It is as rock solid, as i sthe education by example that ASF provides each and every day, by each and every e-mail, and by each and every blog post, on how to do open-source at its best. See
Apache: The “gold standard” for open-source … and pretty as a picture to boot.

So the best way to start a project is, if they will accept it, give it to the Apache folks. This immediately solves any questions about open-source governance, for they insist you transfer ownership of the code to them before they will work on it. If you choose to have your employees participate in the project then Apache will even provide training in how to work as an effect member of an open-source project. This training comes in the forms of Apache’s “incubator process,” one of ASF’s many innovations in open-source management.

However, ASF will only accept code they the deem of some merit, with a purpose consistent with their goals, and under a license they find acceptable, their own. If you want to use GPL, or LGPL, or CDDL, then you will have to make or buy another home for your code.

My experience has been that an open-source project is governed best when it is governed using the Honor Code that I learned in my undergraduate days at Caltech:

“No member of the Caltech community shall take unfair advantage of any other member of the Caltech community.”

Put in the context of an open-source project, this becomes:

“No member of the open-source community shall take unfair advantage of any other member of the open-source community.”

As things stand now, even if Sun believes OpenDS to be a “true” open-source project, many others do not, including some of the key developers.

The ball is now in Sun’s court. If Sun wants OpenDS to be a true open-source community, then I suggest that a senior Sun executive must make the public statement, be it in a press-release or in a blog post, that:

Sun commits that it will not take unfair advantage of any member of the OpenDS community.

Lacking such a commitment, anyone who continues to participate in the project should accept they are doing so as an unpaid employee of Sun, though having the code available under an open-source license may provide sufficient incentive for some to decide to continue working on the project.

Also, without such a commitment, Sun will be saying the project is not that important. I expect this would lead to even more developers leaving.

Red Hat Shopper’s Guide Gets It Right

Red Hat Magazine has just published a “geek” gift guide, Geek gift guide 2007.

Being a proud geek myself, I took a look to see if they got it right.

Indeed they did, for number two on their list is the OLPL XO Laptop. Number one is a wi-fi detecting T-shirt. This seems an odd choice, as the last time I checked my body cannot directly send or receive wi-fi signals.

But at least they had the XO on their list.

Others were not so smart. The New York Times is an example, as I should describe in a forthcoming post.

By the way, I will soon be installing Red Hat’s Fedora on one of my Linux boxes so I get a feel for the run-time they are providing for the XO.

Here’s a tip of my yet-to-be-received own Red Fedora to Red Hat, both for this article, and especially for their support and active participation in the OLPC project.

On Volunteerism: Cast thy bread upon the waters for thou shalt find it after many days

I started a new project yesterday to honor the memory of Pvt. Isaac T. Cortez. A member of the U.S. Army Tenth Mountain Division, he was killed in Iraq last week. See Fallen Soldier: Pvt. Isaac T Cortez: From the Bronx to Iraq to a Return Home, Too Soon.

I knew what would happen when I published the post, and am writing to confirm that, sad to say, my expectations were met.

I did a Google search last night on “Pvt Issac T Cortez” late last night and found that my single post was already #8 in the list returned by Google. I just checked again a few minutes ago and saw that it is now #6.

This is what I expected. In less than a day I have become one of most cited sites about Pvt. Cortez. None of the matches with a higher rank was written by an individual.

I wish I were #200 or so in this list, though I expect my rank will rise even more as I write about him, for those with higher rank are basically just announcements of his death. Those sites will soon move on to other soldiers, so those soldiers can receive the recognition that is their due. This is course means that Pvt. Cortez is only going to get a small amount of recognition, even though he is due much more. Indeed, he is due as much recognition as this nation can muster, but we’ve probably already mustered most of what he will get.

This, by the way, demonstrates an important point about being a volunteer. You do it because you feel you should do it, or want to see what happens if you try to do it. However, you need to expect that little if any recognition will come your way, and for the most part you will probably be doing your work alone.

Doing this work alone can be hard, and thus lead to reducing, and perhaps even ending, your volunteer efforts.

The most important way to ensure that your volunteer work will continue is to be very selective in choosing the cause you wish to advance or support, and your work may even lead to your joining other causes, as has happened to me.

The rewards however, can be great, and many will come in ways you didn’t expect.

All this has been known for some time, though each volunteer has to sort it out for themselves.

If you are considering doing volunteer work, or seek encouragement to continue the work you are already doing, I direct your attention to Ecclesiastes 12:1 (King James Version):

Cast thy bread upon the waters: for thou shalt find it after many days.

Bad Things Happen Can Happen With Good Software

Mr. Serdar Yegulalp of Information Week recently published the post When Bad Things Happen With Good Software, which says in part:

If you create a piece of open source software and discover that it has been put to use in a way you find personally distasteful or immoral, what would you do about it?

What sort of social stipulations, if any, would you place on your software? Or, if you do already, what are they?

The article raises an important point, and Mr. Yegulalp’s analysis is quite extensive.

The essential aspect of the article can be expressed quite succinctly, with my answers to the questions posed by him in italic:



If you create a piece of open source software and discover that it has been put to use in a way you find personally distasteful or immoral, what would you do about it?

If software is open-source then it must meet the terms of the Open Source Definition. Part of the definition is as follows:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

You cannot limit how open-source software is used. Them be the rules.


What sort of social stipulations, if any, would you place on your software? Or, if you do already, what are they?

You can’t place any social stipulations on open-source software, as to do so would limit its fields of endeavor. All that is required of the user is that they meet the terms and conditions of the license. No more, no less.


By the way, bad things can also happen with bad software, as is all to often demonstrated by Microsoft.

  • Pages

  • December 2007
    M T W T F S S
    « Nov   Jan »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • RSS The Wayward Word Press

  • Recent Comments

    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…
    James Murray on On being the maintainer, sole…
    mrrdev on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated