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:
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:
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.