We'll see | Matt Zimmerman

Andrew Tridgell: Patent defence for free software

I missed the start of this talk, but when I arrived, Andrew was explaining how to read and interpret patent claims. This is even less obvious than one might suppose. He offered advice on which parts to read first, and which could be disregarded or referred to only as needed.

Invalidating a patent entirely is difficult, but because patents are interpreted very narrowly, inventions can often be shown to be “different enough” from the patented one.

Where “workarounds” are found, which enable free software to interoperate or solve a problem in a different way than described in a patent, Andrew says it is important to publish them far and wide. This helps to discourage patent holders from attacking free software, because the discovery and publication of a workaround could lead to them losing all of their revenue from the patent (as their licensees could adopt that instead and stop paying for licenses).

Michael Koziarski: Lessons learned from a growing project

Michael, a member of the Rails core team, introduced himself as a pragmatist who is not interested in the principles of free software, only in working with the best tools he can find (many of which are actually proprietary). He gave an overview of what Rails is and where it came from, and a list of lessons he learned from its history.

Michael says that users make the best contributors, because they work to address user needs (which they understand first-hand). He contrasted this with developers who join the project to experiment with the latest technology or rewrite code without good reason. Therefore, in order to gain more contributors, it is important to market the project and attract more users.

He downplayed the conventional wisdom of “release early and often”, recommending a release early enough that there is plenty of incomplete work which contributors can help with, but not so early that the software is useless. In other words, release early, but not too early, and often, but not too often.

As is becoming thematic for the free software community, he recognized the necessity of dealing appropriately with people who do not advance the aims of the project. His example was people who don’t really want to use the software, because there is something about it they don’t like. Unless this one thing is changed, they say, it is of no interest to them. They may imply, or even state outright, that if the project changed in some way, they would join enthusiastically. Michael says that this is often untrue, and that even if they get the feature they want, they will not become valuable contributors. He also spoke of addressing trolls, not just the obvious ones, but more respectable-looking pundits as well.

Rails attracted many users early on because of its upstart status, and Michael pointed out that these people later left the project as it became more mainstream. The same was true of contributors, who left for other projects for their own reasons, to learn new things or explore a different direction.

Over time, the number of willing volunteers in the Rails community was much greater than the corresponding stack of “work to do”. Contributors became furious because their contributions were neglected; they threatened to fork the project and left the community. He stressed the importance of avoiding this scenario by tending to these contributors and their contributions.

He advised (mostly) ignoring your project’s competitors as a means of staying focused on the project’s core vision. In particular, he says that projects which define themselves in terms of their competition (“foo is like Rails, but…”) are not worth paying attention to.

He praised Rails’ use of a more permissive (non-copyleft) license, because it encouraged the growth of an ecosystem of hosting providers and tools. I didn’t quite follow his argument as to why this was.

Some of Michael’s lessons resonated with my experience of Ubuntu’s growth, while others did not. Regardless, it was useful to hear his perspective, and the differences may highlight the differing characters of the two projects.

Lindsay Holmwood: Flapjack

Lindsay introduced Flapjack, which is a monitoring system designed to meet the scalability and extensibility requirements of cloud deployments. It shares the Nagios plugin interface, and so can use the same checks. It uses beanstalkd as a central message queue to coordinate the work of executing checks, recording results and making the appropriate notifications. Each of its components (worker, notifier, database) can be extended or replaced using an API, providing a great deal of flexibility.

Jeremy Allison: Microsoft and Free Software

Jeremy took us through Microsoft’s recognition of, and response to, the threat of free software to their monopoly position. After reviewing the major legal battles of this ongoing war (and the metaphor is apt), he says that Microsoft is turning to patents in an attempt to split the free software community and to earn revenue from the use of free software. Jeremy predicts that the outcome will be a never-ending conflict.

The key conflicts are likely to be around netbooks, mobile phones and appliances. How should the free software community respond?

We could ignore it, and keep making free software under copyleft licenses. Jeremy points out that this is perhaps our most effective strategy in the long run, to stay focused on the vision of a free software world.

We can continue to pressure governments and corporations to adopt truly open standards, and to investigate and challenge monopolies. Transparency is key to these efforts, as “elephants like to work in the dark” (Microsoft being “the elephant in the room”).

By lobbying against software patents, we can hope to contain the US software patent system from the rest of the world. Otherwise, the rapidly accumulating software patents in the US can suddenly and dramatically spread.

We might even convince the likes of Microsoft that patents, and patent trolls, represent a greater harm than good.

In response to direct patent attacks, we should search for prior art and attempt to undermine unjust patents. He also suggests calling out Microsoft employees on the company’s actions, to promote awareness particularly in the context of free software conferences.

He closed with a hope that Microsoft could change, citing IBM as having been “as feared and hated as Microsoft is today”.

Neil Brown:Digging for Design Patterns

Neil explored various design patterns in the kernel in order to illustrate how they are discovered, what their important attributes are, and how to use them effectively.

His examples were a binary search, “goto err”, accessor functions and kref. Naming patterns is important, especially getting that name into the code itself, so that it helps to cross-reference use, implementation and documentation of the pattern (e.g. uses of the kref pattern are sprinkled with the word “kref”). A successful pattern can both help to find bugs (this binary search doesn’t look the same as that one…why?) and to avoid bugs (by getting it right the first time).

Benjamin Mako Hill: Antifeatures (keynote)

Mako delivered an entertaining and inspirational talk on antifeatures, those oddities which intentionally make technology less useful to its consumers (think DRM, though he provided a wide range of examples). Mako explained the main reasons why antifeatures exist, and how they are endemic to the business of proprietary software.

Mako offered a potential upside to antifeatures, which is that they can help the free software community to focus on fundamental concerns like autonomy, rather than (for example) the mechanics of licensing. Antifeatures can be used to explain to the uninitiated why software freedom is important to everyday folks, not just hackers.

Denise Paolucci and Mark Smith: Build Your Own Contributors, One Part At A Time

Denise and Mark provided a practical list of “dos” and “don’ts” for building a successful community based on respect, empowerment and collaboration. Much of this was elementary from an Ubuntu perspective, but they offered a variety of examples from Dreamwidth which were illustrative.

Their list of “three things to start right now”:

1. appoint a “welcomer” and laud newcomers’ first contributions
2. stop timing out on communication when people need responses from you
3. Have words with “that person” and let them know their behavior is not okay

Chris Double: Implementing HTML5 video in Firefox

I knew I liked this idea, but I didn’t realize how much I liked it until I watched Chris’ very informative talk. The promise of an open standard for embedding video is exciting enough, but the standard offers much more than basic embedding and playback controls. Chris demonstrated javascript-driven subtitles loaded from an SRT file, custom controls, copying and analysis of pixel data, replacing the background in a video using a chroma key technique, and even more impressive real-time special effects.

The initial implementation used the xiph.org reference libraries (libogg, libtheora, libvorbis) and PortAudio, but had some problems, including poor A/V synchronization. The second iteration used higher level libraries liboggz, libfishsound, liboggplay and libsydneyaudio, and was included in Firefox 3.1 alpha and beta, but some limitations in liboggplay (a/v sync, chained oggs, etc.) led to difficulty. There were also proof of concept implementations which used GStreamer on Linux, DirectShow on Windows, and QuickTime on MacOS, but these were hampered by codec plugin complications. In the end, they’ve gone back to using the xiph.org reference libraries (but with libsydneyaudio), though the GStreamer backend is still actively developed. Chris has published a series of articles on his blog on reading, decoding and synchronizing A/V streams using various libraries.

There are still some kinks to work out: the lack of indexes and the like in Ogg complicates seeking, calculating duration and so on, and there is no satisfactory solution for cross-platform audio. Rendering is not hardware accelerated yet because the video element is part of the HTML rendering pipeline.

It will be very powerful when it’s ready, though. Theora playback is supported in Chrome, Firefox and Opera today, and Daily Motion, Wikipedia and Archive.org are using it. I can’t wait to see the full API working well on a massive scale.

After lunch, I had a three-way conflict, as I wanted to attend talks on SVG as an alternative to Flash (Libre Graphics Day), gnucash and domain-specific package management.

Sometimes, when I have a conflict like this, I try to attend the talk whose material is less familiar to me (in this case, probably the SVG/Flash one). However, since the talks are being recorded and made available on the Internet, this changes the dynamic a bit. I don’t have to miss out on watching anything, as I can download it later. So, it makes more sense for me to go where I can best participate, taking advantage of my presence at the conference.

Distro summit: Package management

So, I chose to attend the package management talk, as I might have something to contribute. It was about how to harmonize general distribution packaging mechanisms (dpkg, RPM, etc.) with special-purpose ones like those used by Ruby (gems), Lua (rocks), Perl (CPAN modules) and so on. The solution described employed a set of wrapper scripts to provide a standard API to these systems, so that they could be used by the distribution package manager to resolve dependencies.

Due up next was Scott James Remnant’s talk on booting faster, but due to travel difficulties, he hadn’t arrived yet. Instead, we had a free-form discussion on various other challenges in the area of package management.

I took the opportunity to put forward an idea I had been thinking about for some time, which is that we may need to move beyond a “one size fits all” or “everything is a package” approach to package management. Modern package management systems are very capable, and solve a range of difficult problems with a high degree of reliability. The cost of all of this functionality is complexity: making packages is difficult. The system can be made to work for a wide range of software, but the simple case is often not very simple.

I also made the point that there are non-technical challenges as well: it is difficult for developers and ISVs to understand the ecosystem of distributions, and even more difficult to succeed in making their software available in “the right way” to Linux users. The obstacles range from procedural to cultural, and if we only approach this as a technical problem, we risk adding more complexity and making the situation worse.

The opportunity to have this kind of participatory discussion really validated my decision about how to choose which talk to attend.

Liz Henry: Code of our Own

Back in the Haecksen/LinuxChix miniconf, Liz Henry presented an action plan
for increasing the involvement of women in open source, with many well-considered “dos” and “don’ts” based on observations of what has and has not worked for open source communities.

It was the first opportunity I’ve had to attend a free software conference session which went beyond the typical “yes, this is important” and “yes, there really is a problem here” content which is unfortunately as necessary as it is commonplace.

I won’t attempt to summarize it here, but I can definitely recommend Liz’ presentation to anyone who is looking for concrete, actionable methods to promote gender diversity in their technical communities.

Lucas Nussbaum: The Relationship between Debian and Ubuntu

Historically, in Lucas’ assessment, many Debian developers have been unhappy with Ubuntu, feeling that it had “stolen” from Debian, and was not “giving back”. He said that bad experiences with certain people associated with Canonical and Ubuntu reflected on the project as a whole.

However, he says, things have improved considerably, and today, most Debian developers see some good points in Ubuntu: it brings new users to free software and Debian technology, it provides a system which “just works” for their (less technical) friends and family, and brings new developers to the Debian community.

There are still some obstacles, though. Lucas says that many bugfix patches in Ubuntu are just workarounds, and so are not very helpful to Debian. He gave the example of a patch which disabled the test suite for a package because of a failure, rather than fixing the failure.

He felt that Canonical offered few “free gifts” to Debian, citing as the only example the website banner on ubuntu.com which was displayed for Debian’s 15th anniversary. I felt this was a bit unfair, as Canonical has done more than this over the years, including sponsoring DebConf every year since Canonical was founded.

It occurred to me that the distinctions between Canonical and Ubuntu are still not clear, even within the core free software community. For example, the “main” package repository for Ubuntu is often seen to be associated exclusively with Canonical, while “universe” is the opposite. In reality, Canonical works on whatever is most important to the company, and volunteers do the same. These interests often overlap, particularly in “main” (where the most essential and popular components are).

Lucas speculated that more mission-critical servers run Debian pre-releases (especially testing) than Ubuntu pre-releases. It would be interesting to test this, as it’s rare to get sufficient real-world testing for server software prior to an Ubuntu release.

Lucas presented a wishlist for Ubuntu:

• more technical discussions between Ubuntu and Debian (particularly on the ubuntu-develdebian-devel mailing list
• easier access to Launchpad data
• Launchpad PPAs for Debian

The prominence of Launchpad in these discussions spawned a number of tangential discussions about Launchpad, which were eventually deferred to tomorrow’s Launchpad mini-conf. One audience member asked whether Debian would ever adopt Launchpad. The answer from Lucas and Martin Krafft was that it would definitely not adopt the Canonical instance, but that a separate, interoperating instance might eventually be palatable.

I made the point that there is no single Debian/Ubuntu “relationship”, but a large number of distinct relationships between individuals and smaller groups. Instead of focusing on large-scale questions like infrastructure, I think there would be more mileage in working to build relationships between people around their common work.

Earlier this year, the Technical Board agreed to establish a Developer Membership Board (DMB) with responsibility for approving new Ubuntu developers and granting them the appropriate privileges in Launchpad.

Previously, this had been the responsibility of the Technical Board itself. For various reasons, it was prudent to separate this function into its own governance board, for example:

• The Technical Board had been responsible for new core developer applications, while the MOTU Council was responsible for new MOTU applications. This was confusing for applicants, as the two groups evolved different processes, and doesn’t make as much sense in the context of the reorganization of developer privileges. The DMB will be a central governing body for all developers, regardless of which teams they contribute to.
• The Technical Board would prefer to conduct all of its discussions in public, while DMB may have cause for private deliberation. This means that the TB mailing list can be public now.
• The TB had difficulty keeping up with applications in addition to serving its other functions. In particular, TB meetings were difficult to keep on schedule.

Now that the DMB is formally established and active, we would like to hold an election to determine its membership. Until now, the members of the Technical Board have been standing in to fulfill the functions of the DMB.

Because the DMB comprises the functions previously served by the Technical Board and the MOTU Council, the current members of those teams are automatically nominated. Any members of the Technical Board or MOTU Council who *do not* wish to stand for election to the DMB will need to explicitly decline the nomination.

This is an open election, so anyone else may be nominated as well. Candidates should be well qualified to evaluate prospective Ubuntu developers and decide when to entrust them with developer privileges.

There will be a total of 7 seats on the board, chosen by Condorcet voting, similar to the Technical Board election earlier this year.

Nominations should be sent to developer-membership-board@lists.ubuntu.com.

I’d like to bring your attention to a little-used feature of Ubuntu which helps connect the web to the vast repository of software which is packaged for Ubuntu: apturl.  It has been included in Ubuntu installations since 7.10 (Gutsy), but isn’t yet widely used on the web.  Have a look at it and see if it might be useful to you.

Here are some examples of how you can use it:

• If you’re the maintainer of an application which is packaged in Ubuntu, add an apturl link to your site so that Ubuntu users can simply click to install it: If you’re running Ubuntu, check out Banshee
• If you’re the author of a how-to document, replace apt-get commands or Add/Remove instructions with a simple hyperlink: Step 1: To get started making screencasts, install gtk-recordmydesktop
• If you’re writing a blog post or other content where you make reference to an application, include an apturl link so that readers can follow along by installing it: I’m eagerly following the development of Gwibber in Karmic

It would be fantastic if someone came up with a “Get it for Ubuntu” image and a small, embeddable HTML fragment which could be used for these sorts of links.  Meanwhile, please try it out and let us know what you think of it.

Update: WordPress completely destroys the apt: links in this post. Boo! Refer to the wiki pages for syntax examples.

Free software is a remarkable phenomenon.  It is a highly evolved form of collaboration: compared to other creative endeavors, free software developers all over the world are able to work together on a project with surprisingly little friction.  It is a grassroots political movement which has grown from small online communities to span geographical and national boundaries.  It is a multicultural social group with unique and diverse characteristics.  It has spawned a variety of self-governing organizations and successful corporations.

It is also an interesting example of a gift economy.  In general, participants in free software donate their work to the greater good, with no expectation of an exchange of value.  Some contributions are rewarded by social or professional recognition, where the author achieves standing among their peers or receives gratitude from recipients of their work.  Others indirectly evoke rewards in kind, such as where the creator of a program is rewarded by contributions from others which improve it further.  Some are works for hire, where a corporation commissions a contribution through its employees, in pursuit of its own aims.  There are other types of exchanges where I do not personally understand what motivates the contributor.

There are many recognized roles in free software, but they can be broadly classified into three types:

Developers are the heart of this economy.  They are continuously creating and improving free software technology, and publishing their source code for other developers to use and learn from.  Some developers write one program and then vanish from the community, while others contribute to many different projects over the course of decades.  Highly effective developers are celebrities in the free software community.

Users, also known as “people”, are the reason why software is written.  Their needs and wants determine which software is considered valuable.  Many of them also contribute directly to free software in one way or another, by promoting awareness, providing testing and feedback, supporting other users, writing documentation, or building communication links.  Historically, most users of free software were also its developers, but today, this is no longer true, and millions of people use free software who are not developers.

Packagers connect these two groups.  They gather up the source code produced by developers, wrap it in standardized packaging, and bundle it into collections (distributions) designed to meet the needs of users.  Users experience free software almost exclusively through a distribution.  As the free software stack has grown in size and complexity, so have distributions, and the maintenance of a modern distribution is a large-scale development project in itself: selecting appropriate software and versions, getting the lot working smoothly together, and releasing it in the form of a product which is accessible to users.  Packagers create only a small fraction of the software included in their distribution, but they define several key aspects of “what it is like” to use it.  Users most strongly associate their experience of free software with a distribution.

If free software were film, developers would be some combination of writer and crew, creating and expressing characters and a story.  Users would be viewers (including critics and fans), who receive and interpret the work.  Packagers would be the film crew, realizing the production on film so that it can be seen.

If free software were food, developers would be chefs, developing recipes and cooking.  Users would eat and critique the dishes.  Packagers would be restaurateurs, serving customers and creating an environment in which they can experience the food.

Neither of these analogies are very complete.  In particular, these analogies fail to capture the strange loops of free software.  Every developer is also a user, reliant upon of thousands of other programs which they receive in packaged form order to do their development work.  Every team of packagers develops some software in order to make their distribution work, and they use the distribution itself in order to do so.

Distributions, and the integration work that they do, are a critical part of this ecosystem.  Many of us would not be using free software today if not for the efforts of projects like Debian, whose mission is to produce a complete system out of free software created by others.  In my case, Debian provided both the means and the motivation for my contributions to free software, and later made Ubuntu possible.

Strong, productive relationships between these groups are essential to continuing the growth and development of free software.  Whichever groups you’re part of, get to know your counterparts in other groups.  Talk to the people who are packaging your software, writing the software you package, using your software or packages.  Learn about the problems they face and how you can help each other.  Don’t assume that this communication is someone else’s job: reach out and make it happen.

Daniel “Holy” Holbach has announced Ubuntu Developer Week starting Monday, 1st September.  This is a fantastic opportunity for anyone interested in Ubuntu development to get a first-hand look at what developers are working on and learn how to get involved.  The previous one was a huge success, and I hope this one will be even more so.

For my part, I’ll be hosting a Q&A session “Ask Matt” on Friday, at Daniel’s request.  I’ll do my best to answer anything which comes up, but am particularly interested in questions about community-oriented development, the software technologies used in Ubuntu, and what we do at Canonical.