David Herron's Blog

Open source project maintanence

You may have heard of this announcement "it's a matter of when" .. well, that's turned into a lot of planning and meetings and discussions inside the java team. I haven't been able to post any blog entries, because my time has been consumed with those discussions and there's basically very little I can say because of the nature of those discussions.

But what just came to mind is an open source project I once led .. long before the phrase "open source" had been invented. And, how I contributed to the death of that project due to mishandling its governance.

In the 1980's I was a system/network administrator at the University of Kentucky Mathematical Sciences department. Our systems became known as ukma when we joined Usenet in 1985 or thereabouts (which I instigated), and later became known as ms.uky.edu when we joined Suranet/NSFNET a couple years later. One of my roles was running the CSNET connection that, before we joined NSFNET, was the primary path our email took to get onto the Internet. In the 1980's the Internet Service Provider business had not been invented until UU.NET and PSI.NET went into business around 1990.

Because of our CSNET connection I had configured our systems to use MMDF rather than the ubiquitous Sendmail. It was my considered opinion back then that Sendmail had a horrendous configuration file which didn't make any sense, while MMDF's configuration was rather straightforward. It pretty easily handled interfacing to multiple email channels, writing email addresses appropriately for UUCP or BITNET or CSNET or the Internet all with little fuss other than understanding the configuration file details (which were tons easier than Sendmail's).

MMDF began life as a project by Dave Crocker to supply an MTA to the Defense Department. At least I think that was the history. In any case by the time I learned of MMDF, CSNET had adopted it, including handling maintainence. In modern open source terminology, the MMDF project had migrated from Dave Crocker at the Univ of Delaware to Chris Partridge and a couple others at CSNET. I, and my U of KY colleague Ed Bennett, did so much work to fix bugs in our copy of MMDF, that the CSNET team then handed leadership of the MMDF project to us for further maintanence.

We handled the project reasonably well for a couple years. But then we graduated. Ed got a Masters in EE while I got a BS in CS. We both ended up working for The Wollongong Group. Our job was to create a commercial MTA for the networking world of the early 90's, derived from PP, an MTA that handled both the RFC-822 Internet as well as the X.400 ISO world. In the early 90's the X.yyy world of ISO standards was supposedly going to take over networking, but fortunately the TCP/IP Internet won out and the ISO standards are merely an asterisk in network protocol history. That is, except for LDAP which derived from X.500. Our availability to continue MMDF maintainence went to around zero, partly due to time commitment to our employer, and partly because we didn't have system resources to continue MMDF testing and development.

What we should have done, and eventually did, was to hand off maintainence to someone ... but we didn't, for whatever reason.

That meant a long dry period where the project was not maintained. I kept receiving bug reports and fixes, but could only file them away into the MMDF mail folder hoping I could have some time to work on it. Time which never came. There were no updates, and the user community dried up. By the time we handed off MMDF maintanence it was too late because the user community had largely gone away. Due to mishandling governance a worthwhile project (MMDF) lost momentum. I'd like to think that MMDF could have taken a place alongside Exim, QMAIL and Postfix as a viable Sendmail alternative.

Getting back to today ... I'm participating in meetings about open sourcing the Java source, governance models, infrastructure needs, and on and on, and this gives me pause to think about that ancient history.

Comments

• There is a pretty good book called "Producing Open Source Software" by Fogel, I bought it at JavaOne. Most of it you can get on the net of course, but it is a nice summary.

  
  I have a lot of sympathy for people who are mangers/bosses or otherwise in charge of something. If you think coding is difficult, try managing people...
  

  Posted by: larswestergren on June 15, 2006 at 04:30 AM

• Despite the myth about the management powers, I guess the most important thing in order to get a successful Open source project are the smart contributors.. Management and governance seems a secondary criteria for me...

  a nice text about management and development is on the this link at joel on software

  Posted by: felipegaucho on June 16, 2006 at 12:44 AM

• Frankly speaking, I think open source will bring more cost to Sun than now. I think finally every JDK team members will have to concentrate on testing those contributions...

  Posted by: nepalese on June 16, 2006 at 07:16 AM

• Well, that's what we're seeing with the contributions to the JDK today. Each one requires a lot of "handholding" to guide the contribution through our internal processes. We're aware as we move to the open source Java situation that this cost is only going to increase, but it depends on just how we go about the governance.

  Management and governance seems a secondary criteria for me... hmm, perhaps. I can think of a lot of small projects who lack formal governance and are successful anyway. As you say, smart contributors. But I wonder if that's true for large projects? I suspect that our JDK, as an open source project, would fall into the very large category. e.g. over 40,000 source files. That's not lines of code, that's source files, and it's not including the tests.

  Posted by: robogeek on June 16, 2006 at 07:28 AM

• 1.Expose those lightweight component to the open source world, jdk demos, jconsole, those property files needed to be localized and some new features to be implemented.
  2.Move the feedback forum on mustang.dev.java.net to bugs.sun.com. The response time for bug report is very bad now.
  3.Start a Sun Certificated JDK Contributor(SCJC) program to find smart contributor. :)

  Posted by: nepalese on June 16, 2006 at 09:21 AM

This work is licensed under a Creative Commons License.