That situation has now changed; on September 11, Democracy 0.9 was announced. It runs on Linux, and packages for Debian, Fedora Core, Gentoo, and Ubuntu are provided; the source is available for everybody else. Beyond the Linux port, this version promises a polished user interface, a new playlist capability, Flash video support, and more. Your editor clearly had no choice; a tool like this simply must be tried out.
Unfortunately, the Democracy experience is still rather spotty at best. It requires the installation of a number of proprietary codecs (which is not particularly surprising, once one thinks about it - the Democracy developers will have no magic solutions there). The system can be sluggish to respond, and your editor never was able to get it to display a video in its own window. It also would not explain why it failed to display anything, so there was little to be done about it.
But your editor was able to get far enough to realize one important thing: video display is not really what Democracy is about in the first place. This tool is really a sort of video feed aggregator for free video content; it has all the required features for sorting feeds into categories, collecting votes for interesting videos, using BitTorrent to download videos in a provider-friendly way, and more. There is also significant support for people who want to create their own video feeds.
What Democracy and its supporting foundation are trying to do is to get as many people as possible into the business of creating and distributing interesting content. The term "Internet TV" is somewhat off the mark - Democracy will suit couch potatoes just fine, but its real purpose is to get them off their couches and participating in the process. It is trying to create a world where video content is free, universal, and compelling - so it has tools for finding and distributing videos but a distinct lack of DRM support.
This is an important goal - television is too important to leave to the TV companies. If the Democracy system can help to bring more free content into existence, it will have done a good thing. Some progress in that direction has been made: there are, it is said, some 600 channels of free content available now, and, doubtless, more to come. The current code has real promise; it looks like a capable system for discovering, distributing, and managing interesting video content. If they can get past the remaining troublesome issues, the Democracy hackers will have created a valuable tool indeed.an article about the cdrtools license change and resulting controversy. The biggest issue remains the distribution of binary versions of the mkisofs utility. This tool is licensed under the GPL, and has copyrights held by a number of authors. The current version, however, requires the libscg library - which is now distributed under Sun's CDDL license. Since the GPL and the CDDL are mutually incompatible, it is hard to see how mkisofs can be distributed legally.
That situation has not changed in the last month; cdrtools author Jörg Schilling appears to be determined to go forward with the license change. What has happened, however, is that a number of distributors have responded to the change - though not all have responded in the same way. Here is a summary of what the distributors are doing:
Meanwhile, Fedora has also slipped a version of libburn into the Extras repository.
That said, the Gentoo developers have also put cdrkit into their distribution, and it looks like that is what they plan to support going into the future.
The overall picture that results is that, while a number of distributors are taking overt action in response to the cdrtools licensing issues, others appear to be waiting until things settle - and a final 2.01.01 release is made. Only one of the distributors listed above (Mandriva) looks set, at the moment, to distribute a version of cdrtools released under the new license.
For years, there has been occasional talk of forking the cdrtools package. It has remained talk, however; CD burning can be a tricky task, and, as a result, cdrtools is not a trivial package to take on. It now appears likely that this fork will happen at last; the licensing changes have given the distributors (at least those most concerned with these issues) little choice. The real remaining question, then, would be: just how many forks will result? No distributor has an interest in taking on the full maintenance of a package like this, so the incentives should be in place to bring everybody together on a single CD burning utility.
So reviewers are a fundamental part of the process. They are also, it seems, somewhat scarce. Consider a couple of examples:
If we truly believe that code review is a crucial part of the free software process (and, for the most part, it is likely that we do believe this), then the idea that projects are being slowed by the lack of reviewers is a bit worrying. At best, a reviewer shortage will be a bottleneck in the process; a worse possibility is that some projects will simply decide to do without.
Reviewers serve a number of purposes. They can often immediately spot that bug that the developer has stared at for hours without finding. If the code is hard to understand, the reviewers will be the first to notice. If the associated documentation is incorrect or (as is more often the case) absent, the reviewers will notice that as well. When code appears to have been written using some sort of specialized, non-public knowledge, reviewers can inquire as to its provenance. Coding style issues, API misuse, inefficient algorithms, use of outdated interfaces, and more can be caught in the review process before the code hits the project's mainline. Reviewers really do increase a project's code quality and long-term maintainability.
The problem is that code review can be a difficult, tiring, and thankless job. Human nature being what it is, people will often show less than the appropriate amount of gratitude when a reviewer points out their mistakes in public. This is especially true if the code has problems which will require significant amounts of work to fix. The reviewer did not create these problems, he or she is simply the messenger with the bad news. So reviewers tend to get grumpy, especially when they see the same mistakes being made over and over again.
Developers get credit for their work, in various forms. It is a rare project release, however, which publicly acknowledges those who reviewed the code. Given that writing code is not only a more visible activity, but it also tends to be more fun than reviewing code written by others, it is not surprising that many developers choose to concentrate on their own work.
Finally, reviewing code can be intimidating - especially if the patch of interest has a Big Name behind it. Many potential reviewers may feel that they simply do not have the standing to poke at other peoples' work. The fact is, however, that even people with a relatively small amount of experience can provide useful reviews, and learn from the process. From Greg's OLS keynote:
If we want to create the best free systems we can, we must ensure that the review portion of the process does not get slighted. To that end, people who have the requisite skills would do well to dedicate a bit of their time to reviewing code in a project that interests them. Buy a reviewer a beer, and forgive them if they tell you, in front of hundreds or thousands of developers, that your work is best suited for a place in the project's "bad examples" repository. Listen to what the reviewers say, respond to it, and thank them. The result will be better software for all of us.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds