LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||
LWN.net Weekly Edition for May 19, 2005A call for an open media gadget Your editor, recently faced with some long flights, went out and bought himself a portable media player. Despite certain, predictable marital problems caused by the acquisition of yet another expensive electronic toy, the new device has been a great success. It is Linux friendly, plays Ogg files, sounds good, and makes it possible to carry vast amounts of music in a shirt pocket. Since your editor is a fan of live music, he has been especially pleased by the combination of the player and the vast library of concert recordings which is downloadable - with the artists' permission - from archive.org.On the other hand, this device has its annoyances. It boots slowly. The user interface has clearly not been through a serious usability program. The device has a beautiful color display, but most of the space is wasted with silly decorations so that song titles must be scrolled. There are no games to keep the kids happy. And so on. Wouldn't it be nice to be able to go in and hack on the code so that this hardware, which is so full of potential, could be enjoyed fully? Efforts like the open graphics project seek to push forward the state of free graphics through the creation of entirely open hardware. That project is worthwhile, and we wish its developers the best of luck. But here is a question worth asking: might there not be value in the creation of an open media gadget? One could easily put together a wishlist of features: a nice display, substantial internal storage, good analog-to-digital and digital-to-analog hardware, an FM tuner, a low-power FM transmitter, an integrated camera, Bluetooth and/or WiFi networking, etc. But gadgets already exist with most or all of those capabilities. What's missing is this: the platform should be based on Linux, all of the source for the base system should be available, and it should be easy to install new software (and replace existing software) on the system. This gadget should not just tolerate having its operating software ripped out and replaced; it should be designed with that in mind from the beginning. A solid, open platform can inspire a great deal of creativity in the wider development community. Can you imagine what sort of community might gather around a media gadget which is not only open, but which actively encourages its users to hack on it? This device would rapidly develop capabilities unimagined by its creators; if a way could be found to produce it at a reasonable price, chances are that it would be a raging commercial success. Your editor - once his credit card has been returned to him - would gladly buy one. Thanks to over twenty years of work from the free software community, many of us can do our core computing with entirely free systems. But this freedom has not yet extended into many of the other computers that we use every day. Maybe, someday, the consumer electronics industry will realize that, while it makes great hardware, it can do better by letting its customers create much of its software for it. But, while we're waiting, perhaps there are some people with the same sort of drive and skills as shown by the Open Graphics Project who would like to show the industry how it can be done?
A turning point for shorewall Shorewall is a front-end to the Linux netfilter system which makes it (relatively) easy to set up and maintain a firewall. It has a dedicated user community which appreciates Shorewall's flexibility and documentation, along with the ability to secure a system with a minimum of hassle. The current release is 2.2.4.Unfortunately, that may be the last release for a while; Shorewall maintainer Tom Eastep has announced that he will no longer work on the project. Shorewall, it seems, has fallen victim to a common problem with smaller projects: developer burnout. Mr. Eastep has concluded that Shorewall development takes more of his time (and health) than he can afford to give. There appears to be a couple of problems in how Shorewall is developed. The first is that nobody has stepped up to take on a significant part of the load, leaving Mr. Eastep to do all of the work himself:
Unlike the originators of other successful open source projects, I
have not been able to attract a core of people who believe in
Shorewall and who are willing to make sacrifices to ensure it's
success. That is my weakness and I accept it. But is means that I
have been left with trying to develop, document, and support
Shorewall almost single-handedly. I cannot do it any more.
Without having followed the development process for this project, we would be ill-advised to say why things turned out this way. It could be that the Shorewall community did not feel the need to contribute to the project, or it could be that Mr. Eastep, in one way or another, discouraged that sort of involvement. But any project which is dependent on a single person in this way will always be at risk. Mr. Eastep also notes:
And I just cannot deal with the support and documentation
frustration any more -- support, the documentation and the web site
consume an order of magnitude more of my time than does Shorewall
development.
He was apparently unwilling to solve this problem the way many free software developers do: simply ignore support and documentation altogether. The documentation for Shorewall is extensive, to say the least; it clearly took a lot of time. Likewise with support; a reading of the Shorewall mailing list shows Mr. Eastep doing his best to answer most of the questions that were asked. It is not surprising that he got tired of carrying that load. Shorewall is free software, and it almost certainly will not die. There are already some signs that members of the user community are beginning to step up to help ensure that the project continues. This is, of course, one of the strengths of free software; had Shorewall been proprietary, it would now be dead. But the other side of this coin is that the user community has to take an interest in the software it depends on. If users do not come forward over time to help with programming, documentation, and support, they may find themselves having to do it in a hurry when the primary maintainer departs. (Thanks to Matt "Cyber Dog" LaPlante for the heads-up).
Apple and KHTML Apple's use of KHTML and KJS in WebCore, (part of Safari) was widely hailed at the time as a success story between open source and a commercial software company. That was two years ago. Recently, Apple announced that it had passed the Acid2 Test, which prompted users to start wondering when Konqueror would start being Acid2-compliant. This, in turn, sparked a few developers to clarify that Apple's changes to KHTML and KJS were not necessarily in a form that was easily digestible by the KHTML and KJS teams -- in fact, Apple's changes in some parts, using OS X API, make the code more or less incompatible with KHTML and KJS. While Apple is complying with the license (LGPL), it would seem that Apple was not going much further than required by the LGPL. After it became public that the relationship between KHTML and WebCore was not a symbiotic success story between open source and Apple, it quickly turned into a "vs." story in the mainstream IT media, like CNET's "Open-source divorce for Apple's Safari." While the headline may be catchy, it seriously overstates the situation and misses some of the finer points in the relationship. In order to sort through some of the mess to present a more realistic picture, we tried to get folks from both sides to comment. Apple did not respond to a request for comment, but KDE developer Harri Porten was kind enough to respond to questions from LWN. The first question we posed to Porten was what Apple could do in order to make collaboration more possible. Porten told us that it would be a big help if Apple could provide "an open JavaScript/WebCore CVS" to make it easier to track changes. At this point, there is no CVS provided. Apple does provide source tarballs, but nothing to make it easier to merge the code into KHTML or KJS. Porten also pointed us to Zack Rusin's blog and his response to Safari developer Dave Hyatt. Hyatt asked what Apple could do better, and Rusin had plenty of suggestions. Rusin noted that, at this point, Apple and KDE developers had gone in two different directions:
At some point the Open Source ideals which we apply to KHTML and commercial
setup in which you emerge yourself went in two different directions. At
this point we have two completely separate groups developing two different
versions of KHTML. We have absolutely no saying in the way you develop your
version of KHTML and you don't participate at all in the way we develop
KHTML.
Whatever solution we can come up will probably revolve around the following two: either we'll have some say in the way you develop WebCore's KHTML or you will start participating in the way we develop KDE's KHTML. It's basically doing whatever we can to somehow build a bridge between both teams. Rusin suggested sharing a bugs database, having Apple hire someone to merge patches between the KDE and Apple source trees in sync, having Apple more involved in KHTML head development, and several other suggestions. Rusin also suggested that the two teams organize a phone conference. While it's not clear if there's been a phone conference between the two groups, KDE developer Allan Sandfeld reports that there has been an IRC discussion and says that "Apple is being a nice guy for the time being, I will let them announce how things will improve once we have a solution," and asks for "no more 'vs.' stories for the time being." Porten has also said that collaboration between Apple and KDE is "still very well possible at this time."
It's just that the patch merging effort became non-trivial. Nothing that
couldn't be overcome by a more frequent patch exchange, though. The issue
of platform dependent API should be solved by appropriate
abstractions. This approach would help both parties as a cleaner design is
usually easier to maintain and more portable to newer versions of the
underlying system in the future.
Both parties are working hard on finding ways to cooperate more closely in the future. We have to respect each other's needs in terms of release cycles and policies but I'm sure we'll find a way. After all cooperation within KDE works as well although the project is made up of hundreds small but separate entities that all have their different background and motivation. We also asked Porten whether Apple, or any other company, had an ethical responsibility to go beyond the terms of the license and actually cooperate with development. Porten said he didn't want to get into a discussion of ethics, but said that it "often simply makes sense to get engaged further than what the license requires." At this point, it seems that the attention and negative publicity have helped to open the channels of communication between Apple and KDE once again. With any luck, the two groups will be able to find a way to collaborate on KHTML/WebCore in a way that makes sense for Apple and KDE.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||