SCALE: Projects and distribution unfriendliness

Fedora engineering manager Tom "spot" Callaway, who actively maintains a Fedora-compatible package repository for the Chromium web browser, said Friday he has "given up" on getting the browser — which does work well on Fedora — into the distribution proper. In November 2009, he explained why Chromium is not an official Fedora package on his blog, and those issues remain. In a talk at the Southern California Linux Expo (SCALE) entitled, "This is why you FAIL," Callaway, who maintains more than 350 packages in Fedora, listed some of what he sees as "points of FAIL," or distribution-unfriendly software development practices, using Chromium as an example for many of them.

"Having your software be distribution-friendly is a key to success", he said. In the Fedora Activity Day event earlier at SCALE, users brought in systems in a variety of "states of disrepair", he said, which were caused by attempting to install third-party software. Distribution-friendliness also reflects on other channels, he said. The same "points of FAIL" that affect distribution maintainers are also problems for intermediaries who are putting the software on embedded devices or running it as a hosted service.

In the talk, which summarized his chapter, "How to tell if a FLOSS project is doomed to FAIL" from the book The Open Source Way, Callaway discussed the bundled dependency problem. It's worth FAIL points to include a private copy of a library on which a program depends, and extra FAIL points for building a modified version. A key problem, Callaway said, is that when a distribution does a security update for a library, it also has to do updates for any packages that include their own copies. (Fedora has a No Bundled Libraries policy, and Fedora package maintainers do modify the build process for software that the distribution packages, in order to make it build with a system copy of the library.) "Chromium is perhaps the worst offender I have ever seen in my entire career", Callaway said.

Chromium developer Evan Martin, who was not at the event but had posted a list of third-party code distributed with Chromium on his blog, replied to that in email:

Callaway did recognize that some versions of system libraries might not work. The build process should make the system copy the default, though. If the build configuration comes up with "I found this library and I can't use it because it has rabies or something", then it could build an alternate copy. Martin said that the Chromium team is willing to accept outside contributions to facilitate this:

Chromium requires a copyright assignment agreement for code changes, which Callaway said he has not accepted. "After review with a lawyer, they advised me that agreeing to that would give Google a license to use my contributions under any copyright license terms that they'd like, including non-free terms", he said later. "I'd be more than willing to give them my changes under the terms of a Free license, but Google wants to continue to distribute a proprietary version of their browser (Google Chrome), and I have no interest whatsoever in helping them with that effort", he added.

Much of the advice in Callaway's talk applied not to large-scale projects like Chromium, but to new, lower-profile projects. He reserved some of the FAIL warnings for projects that don't offer basic documentation, such as how to do a build and how to begin interacting with the source control system. "Lots of programmers coming through school have never seen a source control system", he said. A project web site should include instructions for how to check out the code and how the project wants to receive incoming code changes. It also counts for substantial FAIL if "all your web site has is a picture of a marijuana leaf", as he said one small-scale open source project does.

The build and install process is another key area. "If your code forces an install into /opt or /usr/local you're probably running Oracle and I'm very very sorry", he said. Running "make install" should just work. "Make the decision that you're going to have an installable program that works outside the source directory."

Some software comes in a problematic archive format; RAR archives are a problem, he said, because the format is proprietary. A developer once asked Callaway about making Fedora packages for his new archiving tool, which came in an archive created by the same tool. "He didn't see why this was a problem and I couldn't tell him because I was crying", Callaway said.

A history of having been proprietary is worth more fail the longer it was proprietary before the initial open source release. "Red Hat has bought some real shiny turds", he said, giving Netscape's email server as an example. "We buried it in the backyard", he said.

The good news is that many of the points of FAIL are relatively easy to correct. Including a copy of the software license and setting up a mailing list are minor tasks. The bundled dependency problem, on the other hand, has turned out to require lots of skilled attention from both the project maintainers and distributions, so that one is still with us.

Both library-bundlers and library-splitters have their points. Bundling creates more long-term issues for administrators, but library-splitting takes up valuable development time, especially for cross-platform projects that need to bundle the libraries for target platforms that don't practice library splitting. But bundled libraries are a problem for many Linux distributions and one that we will likely be facing for some time to come.