Wednesday was certainly a day of big news here at the Open Source Convention. Sun's announcement of the release of StarOffice under the GPL was momentous. I won't say much about this announcement, as it is covered well elsewhere on the O'Reilly home page. I will say that there was the usual mix of relief and skepticism among open source advocates that accompanies licensing announcements, however well-intentioned, from Sun. In this case, there seemed to be grudging respect for what Sun is doing.
Certainly, StarOffice isn't Java; but it is a very useful piece of the open software puzzle that will now be available for use and for modification under GPL. Coupled with the work being done on interfaces, the release of StarOffice promises a more robust desktop for the users of the various Linuxes and BSDs.
There was even more buzz, however, about the new plan for Perl development announced by Larry Wall in his "State of the Onion" address. Larry announced the establishment of working groups on various topics that would replace the "porters" concept in use up to this point. There was lots of emotion surrounding this announcement; the people involved in perl5porters are among the most loyal and most dedicated members of the Perl community, and this announcement will change the way they can be involved with the development of Perl 6.
Larry acknowledged with this announcement that Perl had gotten too big to be fully understood by any one person, or to be developed by informal means (like a mailing list). The working groups will provide a more formal method of making changes, one that will allow a lot more people to contribute or comment on the changes. Development will be more consortium-like.
Most of the people I've talked to like the proposed changes. The hurly-burly development of Perl 5.x has been a trying process for those involved. Details of the new process at this time are skimpy, however, and most people will reserve judgment until they see how the working groups develop.
Larry indicated that Perl 6 could be a big change from Perl 5. Like most major releases, Perl 6 will probably break some existing Perl 5 scripts. Larry says that conversion scripts will take care of most of the changes, but that some small number (5%-10%) of scripts may need some recoding. Only book publishers were pleased to hear that.
Andy Herzfeld's keynote address linked the development of the Apple II and the Macintosh with the hacker culture and the current interest in open source development. Andy, a principal at Eazel and a former member of both the Apple II and Macintosh development team, is uniquely qualified to make this insight.
Andy's talk had too much history in it to suit me (maybe the rest of the audience, most of whom were a generation or two younger than me and thus hadn't lived through it, found it more novel), but I must admit that I gained a lot of respect for Steve Wozniak. If he did half of what Andy said he had done, then he is a brilliant hacker and a dangerous individual.
What is of great interest is Eazel. Tim O'Reilly, who introduced Andy, has argued that the open source movement has been too obsessed with Microsoft. At the same time, the movement is in danger of missing the important new developments while fighting to best the previous technical generation. Graphical User Interfaces and the desktop were two places where Tim noted that tendency. Eazel, however, is an interface that understands the importance of distributed resources and is moving beyond the current desktop metaphor. It's doing so with a Macintosh attitude that takes the user (and usability) into account. Eazel, it should be noted, is built on top of GNOME. GNOME, a free software product, used the GPL; so, therefore, does Eazel. It was a big morning for the Free Software Foundation.
By contrast, Eazel's use of GNOME could be seen as a blow to KDE. Andy made a point, however, to urge both GNOME and KDE to build bridges that will let projects like his work with both environments. I agree that it would be good for open source and free software for these two projects to work more together.
I also attended Greg Wilson's talk on the Software Carpentry Project. For those who aren't familiar with this project, it is an attempt, through a design competition, to create new software development tools. Greg notes that most of the tools programmers now use were created 25 years ago: make, for example. How many devices and objects that you use now were in use 25 years ago?
Greg asserts that computational science is not held to the same exacting standards as experimental science. Nobody checks the code (they may check the algorithms) that graduate students write, and nobody asks to reproduce their data. To bring computational science up to the levels we expect of scientists, we must improve the practices we follow. And our quarter-century-old tools are holding us back.
Greg believes these tools also inhibit open source development. While everyone can read open source code in theory, in practice, it's just not possible for most people. Open source developers fix bugs when they are found; that's the beauty of Eric Raymond's concept of "many eyes." But without good tools, especially in testing, it's difficult to find bugs before they occur. Would you feel sanguine about a car manufacturer who told you, "We'll fix the problems in your car after someone has an accident that demonstrates the problem?" (Okay, maybe car manufacturers do say that, in practice at least. But you don't feel good about it, and the car manufacturers don't print such statements on the outside of their vehicles the way software developers do with their code.)
In any case, Greg asked developers to submit new tools for configuring, building, testing, and tracking software. He received 77 entries; a group of independent judges has reviewed them; and the 10 finalists are now online at his site. He urges us to visit the site and give him our opinions. The winners will be chosen at the end of the month.
Interestingly, the judges decided to put the testing category on hold. The submissions were widely different, and they felt that the quality of the submissions was not as strong. Greg thinks that this difficulty reveals how little formal testing is done within the open software community. Most programmers just aren't that familiar with testing.
I would like to thank my sources for some of this information: Joe Johnston, Andy Oram, Tim Allwine, and Chuck Toporek.
Editor in chief, Technical Publishing
O'Reilly & Associates
Return to: Frankly Speaking