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
which is downloadable - with the artists' permission - from
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
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?
Comments (20 posted)
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
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
(Thanks to Matt "Cyber Dog" LaPlante for the heads-up).
Comments (8 posted)
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
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
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
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
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
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
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.
Comments (9 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Responses to the kernel ELF vulnerability; New vulnerabilities in bzip2, FreeRADIUS, mozilla, squid, ...
- Kernel: Is hyperthreading dangerous?; A new timer API; Clusters and distributed lock management.
- Distributions: FreeBSD 5.4 on AMD64; cAos-2 Linux; MontaVista Carrier Grade Edition 4.0; Symphony OS
- Development: Fish - The friendly interactive shell,
OpenOffice.org and GCJ,
new versions of db.*, Bogofilter, FreeNX, Metasploit Framework,
SSL-Explorer, BRL-CAD, Xfce, Allegro, GIMP,
Smack, Gnumeric, Firefox, Mozilla, Free Pascal, SDCC, Anjuta.
- Press: Apple/KHTML Disconnect, Prior Art How To, EU patents,
Lessig discusses software in Brazil,
Wind River and Linux, Dvorak prophecy.
- Announcements: IBM and Red Hat Solaris to Linux migration, Mandriva results,
FreeBSD 5.4, KDE Turkey, EuroOSCON CFP, ISPCON Baltimore, ITU 2005 CFP,
YAPC::EU::2005 Registration, KDE-Files.org.