We'll see | Matt Zimmerman

I’ve lived in a flat in Islington for about a year now, and in that time I’ve received many letters demanding money.  Annual invoices for council tax recommend that I pay by direct debit.  Flat-rate water bills arrive quarterly.  I’m asked to provide a gas meter reading from time to time.  Two electricity suppliers are still arguing about which of them supplies electricity to the flat, and they both demand payment.

The most insistent, the most colorful, and the most bizarre of all are the letters regarding TV licensing.  I don’t own a television set, nor is one provided by the landlord.  The only television programs I watch are those on rented DVDs, which I view using a computer.  According to their own website, I am not obliged to pay them anything.

Just another bill

Naturally, their first attempt was to send an invoice, which I declined, as I hadn’t ordered anything from them.  This sort of behavior is known as mail fraud in the US.  Scam artists send thousands of invoices to random people, some small percentage of whom pay them or are tricked into agreeing to do so.

WARNING AGAINST UNLAWFUL ACTION

Next, they began to send warning letters.  These, at first glance, accuse the recipient of illegal activity, and “strongly advise” the purchase of a license.  They quote statistics showing how efficient they are at catching “evaders”, even those in the recipient’s own neighborhood!

At this point, I phoned and told them that I did not require a license and would appreciate it if they would stop sending the letters.

Knock, knock

Some time later, a man knocked on our door on a weekend afternoon to investigate.  He stood at the doorstop and asked whether there was a television in the house, and a few other things, and left.

OFFICIAL WARNING

The latest letter threatens us with a “full investigation of the above address” and a “fine of up to £1000″.  This is because “there is still no record of a TV Licence at this property, despite our previous letters.”  They invite me to call them (again) to update their records if I do not require a license.

Given that we have already been visited by an investigator, I wonder what this “full investigation” will entail.  Questioning my neighbors?  Surveillance?  Wiretapping?  Midnight raids?

Woe to those who dare defy the TV police.

Update: On my way home tonight, I saw this advertisement at Charing Cross station.  Watch out!

The Linux Plumbers Conference has ended, and on the whole it was a productive forum despite its rocky start.

One of the reasons for this was that there was a strong presence from the kernel community, carried over from Kernel Summit.  Since the purpose of Plumbers was to explore problems which span subsystems, having these folks in the room was a key factor.  I’m told that it’s unlikely that the conferences will colocate next year, and I hope that it will succeed in drawing participation from kernel developers anyway.

There was a strong sense of cooperation among the different distributions, companies and projects which were represented, though less so between the kernel developers and userspace developers.  These two groups would benefit from a better understanding of one another’s problems, and I hope that can be achieved through cross-participation in working events like Plumbers.

It’s common to picture the ecosystem as a stack or a sphere with some components at the bottom/center and others at the periphery, but these simplistic metaphors belie the complex and non-linear interdependencies which exist between projects.  The kernel, the toolchain, the “plumbing”, applications, distributions, companies, and so on, don’t form a neat diagram, and each performs an essential function in making the overall ecosystem work.

I had a chance to talk briefly with Greg KH about his concerns and the way they were expressed, and have hope that some goodwill can be fostered there.  I introduced him to Pete, who manages our kernel team, as a point of contact for a more nuanced dialog about our working relationship with the kernel community.

The discussions about the boot process were particularly interesting, as a great example of a problem which needs broad cooperation in order to solve effectively.  For example, as a result of comparing the (quite different) bootcharts between Fedora and Ubuntu, developers from both distributions identified areas where significant gains were clearly possible without deep structural changes.  Scott has isolated a long-standing issue which made our module loading sequence in Ubuntu much slower than it could be.

In between talks, I did some work on integrating apport with kerneloops.  The result is that kernel oopses can be captured as Apport problem reports with full detail, and semi-automatically filed as bugs, in addition to being counted on kerneloops.org’s statistics.  I’ve put an initial version into Ubuntu and sent the patch to Arjan for merging upstream, and we’re exploring the addition of kerneloops to our default installation to provide testing feedback to kernel developers from our users.

As the opening keynote at the Linux Plumbers Conference, Greg Kroah-Hartman delivered a talk entitled “The Linux Ecosystem, where do you fit in it?“

There were, let’s say, a few elements of it which I found objectionable.

The central issue, of course, was that he devoted a large portion of the talk to showing that Canonical contributes fewer patches to the Linux kernel than many other companies.  While it’s somewhat flattering for Canonical’s role in the community to be a headline topic for a conference like this, the message that he chose to deliver was a negative one.  He presented list after list of contributors, ranked by number of patches, and pointed out how low Canonical was on each one.

I approached him immediately after his talk to suggest that we have a conversation about the topics he raised, but he wasn’t interested in talking with me at that time.  I made a standing offer to talk with him at any time during the three-day conference, and hope that we can get to the bottom of this.  Until then, I’m not sure what exactly he’s trying to accomplish.

Meanwhile, I’d like to make a few points.  I’ll start with a disclaimer, something that Greg chose to omit from his presentation: I work for Canonical, and am one of the founding members of the Ubuntu project.

Greg’s view of the ecosystem is odd

Greg considers the “Linux ecosystem” to be GCC, binutils, the Linux kernel, X.org, and a handful of other projects.  He disregards most of the desktop stack (including GNOME and KDE), all desktop and server applications, and most anything else that is recognizable to an end user as “Linux”.

Some members of the audience picked up on this and commented.  His justification for this was that these other components are not specific to Linux.  “Any contribution to GNOME also benefits OpenSolaris”, says Greg.  Apparently, this means that GNOME isn’t an important part of Greg’s Linux ecosystem.  “I had to draw the line somewhere”, he says.

This is not the Linux ecosystem that I use and contribute to.

Greg’s figures are wrong

The first slide in his presentation acknowledged that he had miscounted Canonical’s contributions to the Linux kernel.  As he freely admits, his method is not an exact science and there were many other errors.  However, given that he intends to use these statistics to attack Canonical, he should take more care in compiling them.

His original claim, given at a Google tech talk in June 2008, was “Canonical doesn’t give back to the community”.  He supported this by saying that “Canonical made six changes to the kernel in the last five years.”

Greg now states that Canonical has in fact contributed in excess of 100 patches.  This means that his raw data for the kernel was incorrect by two orders of magnitude.

His LPC presentation also put forth some new claims regarding contributions to other projects.  In particular, he lambasted Canonical for not contributing to binutils at all (zero patches).  What that actually means in terms of our position in the ecosystem is debatable, but numbers are not.  It’s true that Canonical does not contribute as much to binutils as Red Hat does (and more on that later), but as Kees Cook pointed out after the presentation, he personally contributed a patch (now merged) which credited Canonical as his employer, which fell within the date range of Greg’s analysis.

Of course, none of these errors impact his fundamental conclusion, which is that Canonical engages in relatively small-scale development compared to Red Hat and Novell.  No one is disputing that.  However, the fact remains that his data is inaccurate.

Greg is failing to disclose his bias

Greg is, of course, a well respected contributor to the Linux kernel, having sustained a significant level of contribution over a period of several years.  I’m grateful to him for his technical contributions, which of course benefit Ubuntu as a consumer of the Linux kernel.  However, his contribution to the public dialog about the Linux ecosystem leaves much to be desired.

We all have bias, and the best that we can do is to disclose it so that others can take it into account when hearing our ideas.  Unlike the presentations given by other Novell employees at this and other conferences, Greg’s slides omitted the Novell logo.

Novell is, of course, a competitor of Canonical, being an operating system vendor (and a large one at that).  To attack his corporate competitors without acknowledging his affiliation is in poor taste.

Greg’s comparisons are bogus

The fundamental argument he makes is that Canonical doesn’t contribute as much as Red Hat, Novell and many other organizations which he names.  This is absolutely true.  He says that it’s unethical to claim more contributions than one has made, and he’s absolutely right there as well.

However, no one, certainly not Canonical, has ever claimed that Canonical does as much Linux development as Red Hat or Novell.  He’s refuting a claim which has, quite simply, never been made.

Canonical is primarily a consumer of the Linux kernel.  It is one of the building blocks we need in order to fulfill our primary mission, which is to provide an operating system that end users want to use.  It is, on the whole, a good piece of software which meets our needs well.  We routinely backport patches from newer kernels, and fix bugs which are particularly relevant to us, but our kernel consists almost entirely of code we receive from upstream.

Why, then, does Greg feel that Canonical should be expected to make more changes to the Linux kernel?

Is it because Ubuntu is a very popular system, with a lot of users?  It is that, but most people who use Linux aren’t kernel developers, so a large user population doesn’t translate to a lot of Linux kernel patches.

Is it because he thinks Canonical is making a lot of money off of the Linux kernel, and should give some of that back?  We make no secret of the fact that Canonical as a company is not yet earning a profit.  We make a promise to our community that we will never charge money for Ubuntu.

Is it because he thinks Canonical developers are writing a lot of patches and not contributing them?  If he does, he hasn’t compared our kernel tree with Linus’.

Why then?

Greg’s approach is not constructive

If we give Greg the benefit of doubt, and assume that he doesn’t merely have an axe to grind, then there must be some genuine concern behind all of this.  He must feel that Canonical is somehow not doing the right thing.

If that’s true, why hasn’t he ever talked to me about it?  He has my email address, and we’ve exchanged mail and spoken on the phone before.  Why am I hearing about this through presentations given to Google employees, posted on YouTube, or delivered to audiences of kernel developers?

To present his commentary in this way is indefensible.  LPC is promoted as a productive community event aimed at solving problems, and Greg has used his voice as a speaker to promote a much less honorable agenda.

When this sort of thing happens on mailing lists, it’s called trolling.

The web is no longer just a collection of sites one can visit with a browser.  It’s increasingly a rich set of programming interfaces upon which applications can be built.  This, at a technological level, is very good news.  Interfaces make possible a greater variety of applications.  This is an old idea for software in general, but a relatively new trend on the web.

Application cooperation

Remember when desktop programs didn’t talk to each other?  Incompatible file formats, proprietary development, primitive multitasking features and monolithic design kept each program in its own silo.  Each one was only as good as what came in the original box, and if you wanted to do more, you had to look for a better program.  Usually, the one you found, with just the right feature you needed at that moment, was missing several others you couldn’t live without.  Power users would keep several different programs for doing different variations of the same task: one word processor had a great macro facility, while the other had beautiful fonts or could open the right file formats.

Proprietary systems were evolving toward a more cooperative model in the 1980s, when technologies like DDE enabled applications to work together in meaningful and standard ways.  Although its capabilities were limited, the benefit to end users was substantial.  There is of course a lot more which has happened in this area since then, but meanwhile, the modern free software movement has brought .  A free program could be improved to add “just one more feature” which would otherwise have required searching for (and perhaps buying) a completely different program.  Sometimes, new capabilities could even be “lifted” from one program to another, or shared as a library between multiple programs.  An improvement in one program could benefit other applications as well.

In short, free software programmers were no longer fundamentally limited by their own time and skill in writing programs: they could build on the work of others.  The programmable web, in some ways, promises even greater opportunities to do this.  The explosion of web APIs, and applications built on them, speaks for itself.  However, this freedom is in some ways more reminiscent of the limited power of proprietary application systems than of free software.

Open interface, closed application

Most web APIs seem to be open for use by anyone, within reasonable limits.  Given that they are, in effect, licenses to use someone else’s computing resources, it’s necessary to regulate their use, and appropriate to charge for the service.  However, non-trivial applications built on them are usually not themselves open.  This means that while application programmers can benefit from the availability of the API, they can’t build on each other’s work.

I can use the API to create a new application, but I can’t use an existing application to make a better one.

Open interface, closed implementation

Similarly, the backend software which provides these useful interfaces is usually proprietary.   Sometimes, this software is in fact free, but the API provider chooses not to share their version, sometimes exploiting a loophole in copyleft schemes which would otherwise require that it be shared.

I can use the API to create an application, but I can’t use it to build a new and better interface.

Developer freedom

What would be the characteristics of an online software ecosystem which promotes innovation at the same level that free software has done?  There are those who say that freedom on the web is about data: who owns the data, and what can they do with it?  These are interesting questions, but I’m more interested in how to promote the development of more and better software, and I think data is only a part of that picture.

A free web, to me, would support innovation through building on existing APIs, backend software and applications.  Everything new which was created would create new possibilities for further development.  The four freedoms largely apply, and for largely the same reasons.  The free software concept is not a complete solution, though, and needs to be adapted significantly for this purpose.  I can think of a few obstacles:

Copying software is virtually free, but providing a web service is not. One of the key benefits of online APIs is that they’re consistently available at a globally addressable location, and that requires high-availability hosting services.  Some providers, like Google App Engine, already offer a basic hosting service for free, but I think these are more likely loss leaders than sustainable free services.

Similarly, many interesting web applications, particularly “user-created content” sites, would be less interesting if they are decentralized.  When the data is fragmented, the overall system becomes less valuable.  Imagine if Facebook were free, and there were hundreds of smaller, specialized Facebooks rather than one large one.  The very thing which makes Facebook interesting (the ability to connect to other people in a variety of ways) would be significantly diminished unless these different instances were connected.  In order to support decentralization, applications need to share data. Unfortunately, building such applications with today’s tools is complex and difficult to get right.

What else is different?  What stands in the way of software freedom for the web?

Well, maybe not the knives.  I visited an acupuncturist today, in the latest scouting mission in my campaign against RSI.  I’ve experienced chronic pain and discomfort in my arms and wrists for years now, and have tried various other types of physical therapy, but this was my first of this type.

I spent most of the session talking with the practitioner, explaining the history of my symptoms.  She was emphatic that I seek to fix the problem at its root by correcting the ergonomics of my workstations.  This is clearly necessary, but in spite of several rounds of experimentation I have not been able to solve it on my own yet.  Thankfully, she was able to recommend a colleague who specializes in this particular area of ergonomics, and I’ll see what comes of that.

The acupuncture treatment itself was a very curious affair.  The sensation of a needle penetrating the thick band of tension in my arm muscles was quite unfamiliar and difficult to describe.  It felt almost as if something were pressing hard on the entire length of the muscle.

It does seem to have relieved some of the tension, and I’m interested to see the effect of repeated treatments.  I’m also left with a curious feeling of lightness which lasted the entire 20-minute walk home.  It was a little bit like having ingested caffeine.

My question of the evening: How long before we have input devices of comparable speed and accuracy which don’t abuse our bodies so?

I’ve decided (somewhat late) to attend the inaugural Linux Plumbers Conference in Portland.  It’s shaping up to be an interesting collection of people and topics.  I think the idea of a conference which spans the kernel/userland boundary is a useful one, though so far it’s pretty heavy on the kernel side, probably in large part due to overflow of topics (and kernel developers) from the preceding Kernel Summit.

I’ll be there to meet up with some far-flung Ubuntu folk and learn about the next round of hurdles which will be faced by integrators like us.

There are interesting changes under way in how software applications are designed and deployed, and I’m curious about the role of Ubuntu will be in this process.  I’m thinking about this in terms of three categories:

1. Desktop applications

Examples: OpenOffice.org, Pidgin, Amarok, GIMP

These are our traditional word processors, spreadsheets, messaging clients, music players, and so on.

End users of desktop applications benefit from high performance, access to local data and offline availability, but are hampered by high maintenance requirements and primitive collaborative features.

Developers of desktop applications benefit from access to local OS APIs, a wealth of existing free source code, and relatively low maintenance overhead, but are hampered by a complex distribution model, multiple platform targets, and many versions being actively used in the wild.

Ubuntu specializes in this area today.

2. Web applications

Examples: Google Docs, GMail, Facebook, Youtube

They are distinguished from simple websites by virtue of having a consistent look and feel throughout, a high degree of interactivity, and a defined feature set.

End users of web applications benefit from the universal availability of the applications and associated data, advanced collaborative features, and virtually zero maintenance, but are hampered by comparatively low performance, unavailability when offline, primitive user interfaces (though they are getting better), and data privacy issues.

Developers of web applications benefit from a simple distribution model, fewer platform-specific issues, and fewer versions to support at once (typically one), but are hampered by high maintenance (production hosting), a more complex user interaction model, and a comparative scarcity of open source code.

Ubuntu aims to provide an excellent browser experience, but doesn’t go much further than that yet.

3. Hybrid web applications

Examples: Google Earth, Adobe AIR applications, iPhone widgets

These applications attempt to draw from the best of both paradigms.  Some are designed and built similarly to centralized web applications, with HTML/JavaScript user interfaces, but actually run in a local runtime environment on the end user’s system and often (but not always) use web APIs.  Others are designed like desktop applications, but rely on web APIs behind the scenes.

Ubuntu doesn’t do much in this area yet.

What does this mean for Ubuntu?

Ubuntu is, most essentially, a means for users to obtain and use applications, and for developers to create them.  Operating systems exist to make these things easier, so changes in this area are highly relevant to us.  They may even lead to reinterpretation of some of our most basic principles, for example:

Every computer user should have the freedom to download, run, copy, distribute, study, share, change and improve their software for any purpose, without paying licensing fees.

How does this apply to web applications which need not be downloaded, distributed or copied in order to be run or shared?  Is it useful to be able to copy, change and improve the source code for a desktop application if all of the interesting functionality is hidden behind a web API?

To what extent can (or should) hybrid applications truly be a part of a free system?  Do they make free software values less relevant, or just less obvious?  These questions are the subject of active debate in the media today.

Once we’ve addressed the philosophical issues, how can Ubuntu take advantage of this innovation at a technical level? How can Ubuntu become a superior platform for hybrid web applications?  The just-announced Google Chrome has interesting implications, both for bringing web applications further into the desktop and supporting hybrid applications.

When performing a task on a computer, what types of objects do you work with?  Files and folders?  Web pages?  Application programs?  Settings?  Each of these have well-established conceptual models which, on a good day, provide some consistency in different contexts.  Files have a hierarchy of folders, web pages have histories and search, applications live in a nested menu, settings have tabbed notebooks, and so forth.  The details of how these work may vary, but the conceptual model is the same.  Donald Norman, among others, tells us this is a good thing, because it makes these systems easier to learn.

Ubuntu top-level menus

In Ubuntu, our top-level navigation (the GNOME panel) includes: Applications (a menu of programs), Places (a hierarchy of files and folders) and System (mostly tabbed settings dialogs with a few odds and ends).  Web pages, for the most part, live in the web browser application, as they do on other systems.

Now, I don’t know about you, but I spend a lot of my time on computers working with people.  But where are they to be found?  Some of them are in my web browser, on social networking websites and blogs.  Others are in my instant messaging client, in channels, conversations and contact lists.  Others are in my email application, in address books and threads.  Still others are at the opposite end of a voice connection.  None of them look or work the same way.

What is a good general conceptual model for people in software?

I think the social networking sites come the closest so far.  There, one’s interactions with people are oriented around social concepts.  People:

• Have a profile which describes them for purposes of recognition and acquaintance.
• Have relationships with other people.  The word “friend” has been abused into common usage on the web to denote “someone who is known to me”.  People are also members of groups, are linked by participation in organizations, and so on.  Relationships organize people just as hierarchical folders organize files.
• Perform activities, which are of interest to people with whom they have relationships.  These may range from trivial status updates to detailed descriptions of recent activity.  Activities provide social context and the opportunity to respond to events.
• May be present and available for synchronous communication (or not) by various means.  Presence provides a notion of who is “here” to interact with right now.

How might we translate these metaphors onto the desktop?

There seem to be plenty of social networking applications, but so far, they’re little more than alternative user interfaces for the corresponding websites, with some added features.  What better place than the operating environment to represent people, who are independent of any particular program or data?  What kind of activities could be possible and natural?

• Collaboratively develop any type of content with your friends, independent of a particular application
• Let your friends know what you’re doing, without having to write about it separately
• Control access to data based on social relationships, rather than abstract credentials like passwords
• Give a copy of any file to your friend as easily as putting it on flash media (this still isn’t easy enough in 2008)

How could it look?  What would a People menu look like?  A simple first attempt might include only people you know, and indicate their presence.  Selecting a person would display an interactive window with their profile, recent activity and associated data.  Controls would enable you to contact them, or share your applications, session, data or activity.  Your ideal email address book and IM contact list would display the same people in the same fashion (Telepathy is helping make this kind of integration possible).

Adding or removing a new acquaintance would instantaneously take effect in all relevant applications: receive an email from someone, add them to your list of people, notice they’re online and show them the new song you’re working on, all in one fluid motion.

Sign me up.