The responsibilities of ownership

Friday, July 22nd, 2011

In the open source community we make a very big deal about the rights of ownership. But what about the responsibilities?

Any asset comes with attendant costs, risks and responsibilities. And anybody who doesn’t take those seriously is a poor steward of the asset.

In the physical world, we know this very well. If you own a house, there are taxes to pay every year, there will be some bills for energy and maintenance, and there’s paperwork to fill out. I was rudely reminded of this when I got an SMS at 2am this morning, care of British Gas, helpfully reminding me to settle up the gas bill for a tenant of mine. If we fail to take care of these responsibilities, we’re at risk of having the asset degraded or taken away from our care. An abandoned building will eventually be condemned and demolished rather than staying around as a health hazard. A car which has not been tested and licensed cannot legally be driven on public roads. In short, ownership comes with a certain amount of work, and that work has to be handled well.

In the intellectual and digital world, things are a little different. There isn’t an obvious lawn to trim or wall to paint. But there are still responsibilities. For example, trademarks need to be defended or they are deemed to be lost. Questions need to be answered. Healthy projects grow and adapt over time in a dynamic world; change is inevitable and needs to be accommodated.

Maintaining a piece of free software is a non-trivial effort. The rest of the stack is continuously changing – compilers change, dependencies change, conventions change. The responsibility for maintenance should not be shirked, if you want your project to stay relevant and useful. But maintainership is very often the responsibility of “core” developers, not light contributors. Casual contributors who have scratched their own itch or met a work obligation by writing a patch often give, as a reason for the contribution, their desire to have that maintenance burden carried by the project, and not by themselves.

When a maintainer adds a patch to a work, they are also accepting responsibility for its maintenance, unless they have some special circumstance, like the patch is a plugin and essentially maintained by the contributor. For general cases, adding the patch is like mixing paint – it adds to the general body of maintenance in a way that cannot easily be undone or compartmentalised.

And owning an asset can create real liabilities. For example, in some countries, if you own a house and someone slips on the stairs, you can be held liable. If you own a car and it’s being borrowed, and the brakes fail, you can be held liable. In the case of code, accepting a patch implies, like it or not, accepting some liability for that patch. Whether it turns out to be a real liability, or just a contingent one, is something only time will tell. But ownership requires defence in the case of an attack, and that can be expensive, even if it turns out the attack is baseless.

So, one of the reasons I’m happy to donate (fully and irreversibly) a patch to a maintainer, and why Canonical generally does assign patches to upstreams who ask for it, is that I think the rights and responsibilities of ownership should be matched. If I want someone else to handle the work – the responsibility – of maintenance, then I’m quite happy for them to carry the rights as well. That only seems balanced. In the common case, that maintenance turns out to be as much work as the original crafting of the patch, and frankly, it’s the “boring work” part, while the fun part was solving the problem immediately at hand.

Of course, there are uncommon cases too.

One of the legendary fights over code ownership, between Sun and Novell, revolved around a plugin for OpenOffice that did some very cool stuff. Sun ended up re-creating that work because Novell would not give it to Sun. Frankly, I think Sun was silly. The plugin was a whole work, that served a coherent purpose all by itself. Novell had designed and implemented that component, and was perfectly willing and motivated to maintain it. In that case, it makes sense to me that Sun should have been willing to make space for Novell’s great work, leaving it as Novell’s. Instead, they ended up redoing that work, and lots of people felt hard done by. But that’s an uncommon case. The more usual scenario is that a contribution enhances the core, but is not in itself valuable without the rest of the code in the project being there.

Of course, “value” is relative. A patch that only applies against an existing codebase still has value in its ability to teach others how to do that kind of work. And it has value as art – you can put it on a t-shirt, or a wall.

But contributing – really contributing, actually donating – a patch to a maintainer doesn’t have to reduce those kinds of value to the original creator. I consider it best practice that a donation be matched by a wide license back. In other words, if I give my patch to the maintainer, it’s nice if they grant me a full set of rights back. While does a bad job with many other things, the Canonical contribution agreement does this: when you make a contribution under it, you get a wide license back. So that way, the creator retains all the useful rights, including the ability to publish, relicense, sell, or make a t-shirt, without also carrying all the responsibilities that go with ownership.

So a well-done contribution agreement can make clear who carries which responsibilities, and not materially diminish the rights of those who contribute. And a well-done policy of contribution would recognise that there are uncommon cases, where a contribution is in fact a whole piece in itself, and not require donation of that whole piece in order to be part of an aggregate whole.

What about cases where there is no clear maintainer or owner?

Well, outside of the world of copyright and code, we do have some models to refer to. For example, companies issue shares to their shareholders, reflecting their relative contribution and therefor relative shared ownership in the company. Those companies end up with diverse owners, each of whom is going to have their own opinions, preferences, ideals and constraints.

We would never think to require consensus on every decision of the board, or the company, among all shareholders. That would be unworkable – in fact, much of the apparatus of corporate governance exists specifically to give voice to the desires of shareholders while at the same time keeping institutions functional. That’s not to say that shareholders don’t get abused – there are enough case studies of management taking advantage of their position to fill a long and morbidly interesting book. Rules on corporate governance, and especially the protection of minority interests in companies, as well as the state of the art of constructing shareholder agreements to achieve the same goals, are constantly evolving. But at the end of the day, decisions need to be taken which are binding on the company and thus binding on the shareholders. The rights of ownership extend to the right to show up and be represented, and to participate in the discussion, and usually a vote of some sort. Thereafter, the decision is taken and (usually) the majority will carries.

In our absolutist mentality, we tend to think that a single line of code, or a single small patch, carries the same weight as the rest of a coherence codebase. It’s easy to feel that way: when a small patch is shared, but not donated, the creator retains sole ownership of that patch. So in theory, any change in the state of the whole must require the agreement of every owner. This is more than theory – it’s law in many places.

But in practice, that approach has not withstood any hard tests.

There are multiple cases where huge bodies of work, composed of the aggregate “patches” of many different owners, have been relicensed. Mozilla, the Ubuntu wiki, and I think even Wikipedia have all gone through public processes to figure out how to move the license of an aggregate work to something that the project leadership considered more appropriate.

I’d be willing to bet that, if some fatal legal flaw were discovered in the GPLv2, Linus would lead a process of review and discussion and debate about what to do about the Linux kernel, it would be testy and contentious, but in the end he would take a decision and most would follow to a new and better license. Personally, I’d be an advocate of GPLv3, but in the end it’s well known that I’m not a big shareholder in that particular company, so to speak, so I wouldn’t expect to have any say ;-) Those who did not want to follow would resign themselves to having their contributions replaced, and most would not bother to turn up for the meeting, giving tacit assent.

So our pedantic view that every line of code is sacred just would not hold up to real-world pressure. Projects have GOT to respond to major changes in the world around them. It would be unwise to loan a patch to a project in the belief that the project will never, under any circumstances, take a decision that is different to your personal views. Life’s just not like that. Change is inevitable, and we’re all only going to be thrilled about some subset of that change.

And that’s as it should be. Clinging to something small that’s part of someone else’s life and livelihood just isn’t healthy. It’s better either to commit to a reasonable shared ownership approach, which involves being willing to show up at meetings, contribute to maintenance and accept the will of the majority on major moves that might be unpalatable anyway, or to make a true gift that comes with no strings attached.

Sometimes I see people saying they are happy to make a donation as long as it has some constraints associated with it.

There was a family in SA that lived under weird circumstances for generations because a wealthy ancestor specified that they had to do that if they wanted access to their inheritance. It’s called “ruling from the grave”, and it’s really quite antisocial. Either you give someone what you’re giving them, and accept that they will carry those rights and responsibilities wisely and well, or you don’t give it to them at all. You’re not going to be around after your will is executed, and it’s impossible to anticipate everything that might happen. It’s exceedingly uncool, in my view, to leave people stuck.

It’s difficult to predict, in 50 or 100 years time, what the definition of “openness” will be, and who will have the definition that you might most agree with. In the short term we all have favourites, but every five or ten years the world changes and that precipitates a new round of definitions, licenses, concepts. Consider GPLv2 and GPLv3, where there turned out to be a real need to address new challenges in the way free software is being used. Or the Franklin Street Declaration, on web services. Despite having options like AGPL around, there still isn’t any real consensus on how best to handle those scenarios.

One can pick institutions, but institutions change too. Go back and look at the historical positions of any long-term political party, like the UK Whigs, and you’ll be amazed at how a group can shift their positions over a succession of leaders. I have complete trust in the FSF today, but little idea what they’ll be up to in 100 years time. That’s no insult to the FSF, it’s just a lesson I’ve learned from looking at the patterns of behaviour of institutions over the long term. It’s the same for the OSI or Creative Commons or any other political or ideological or corporate group. People move on, people die, times change, priorities shift, economics ebb and flow, affiliations and alliances and competition shift the terrain to the point that today’s liberal group are tomorrows conservatives or the other way around.

So, if one is going to put strings attached to a donation, what does one do? Pick a particular license? No current license will remain perfectly relevant or useful or attractive indefinitely. Pick an institution? No institution is free of human dynamics in the long term.

If there’s a natural place to put the patch, it’s with the code it patches. And usually, that means with the institution that is the anchor tenant, for better or worse. And yes, that creates real rights which can be really abused, or at least used in ways that one would not choose for ones own projects.

And that brings us to the toughest issue. How should we feel about the fact that a company which owns a codebase can create both proprietary and open products from that code?

And the “grave” scenario really is an issue, in the case of copyright too. When people have discussed changes to codebases that have been around for any length of time, it’s a sad but real likelihood that there are contributors who have died, and left no provision for how their work is to be managed. More often than not, the estate in question isn’t sufficiently funded to cover the cost of legal questions concerned.

The first time I was asked to sign a contribution agreement on behalf of Canonical, it was for a competitor, and I declined. That night, it preyed on my conscience. We had the benefit of a substantial amount of work from this competitor, and yet I had refused to give them back *properly* our own modest contribution. I frankly felt terrible, and the next day signed the agreement, and changed it to be our policy that we will do so, regardless of what we think about the company itself. So we’ve now done them for almost all our competitors, and I feel good about it.

That’s the magical thing about creation and ownership. It creates the possibility for generosity. You can’t really give something you don’t own, but if you do, you’ve made a genuine contribution. A gift is different from a loan. It imposes no strings, it empowers the recipient and it frees the giver of the responsibilities of ownership. We tend to think that solving our own problems to produce a patch which is interesting to us and useful for us is the generosity. It isn’t. The opportunity for generosity comes thereafter. And in our ecosystem, generosity is important. It’s at the heart of the Ubuntu ethic, and it’s important even between competitors, because the competitors outside our ecosystem are impossible to beat if we are not supportive of one another.

Marcus and Ivanka in the Canonical Design team sat me down for some words of wisdom a few months ago. “You think you need a logo, but what you really need is a new font. One that sets the standard for both professional design, and embracing the values of Ubuntu in the way it’s produced.”

And how right they were.

Figuring that we wanted to do this once, properly, we said we’d build a complete family: various weights, variable-width and mono, across some of the key language groups of our community. We knew we couldn’t do everything but we figured we could establish a rigorous core upon which everything could be done. We’d fully hint and kern the work too, so it’s good enough to be a default interface font for something we all use all day long. A huge project, one that will take some time to finish. But today we’re publishing the first source for Ubuntu, the font, a milestone worth celebrating.

Marcus introduced Bruno Maag of Dalton Maag, who expressed a willingness to engage around an open font, and we agreed to buy the rights to the work completely, so that it could be licensed freely.

Bruno pulled together a very energetic team of typographers: Lukaz, Amelie, Shiraaz, Malcolm and more, all folks who live and breathe type and typography and keen to explore this rather crazy idea of inviting crowds into the inner sanctum of type design.

We knew at the start we were bringing together two very different worlds. We wanted a process which would ensure participation without drowning out the clear leadership needed for a coherent result. Bruno steered Marcus, Ivanka, me and others through a core initial process where we defined the range and scope of what we wanted to take on, and the values we wanted reflected in the result. I learned that a font is grounded in real values, and fortunately we have a strong expression of the six attributes that we value in Ubuntu and Canonical: collaboration, freedom, precision, reliability, adroitness, accessibility. That small team was best positioned to distill those into the typeface, and shape the broad strokes of the work.

Ubuntu is a global phenomenon, and we knew at the start we didn’t have the breadth of eyeballs close at hand to keep the font on track as it expanded. So we planned a process of expanding consultation. First within Canonical, which has folks from nearly 30 countries, and then within the Ubuntu community. We published the font to Ubuntu Members, because we wanted folks who participate and contribute directly to Ubuntu to have the strongest say in the public process of designing the font. We heard from Greek, Turkish, Hebrew, Arabic, Indian, Chinese and many other cultures. Not everyone has glyphs in this first round, but everyone has had a hand in bringing us to this milestone.

The design team needed help with this outreach program, and it turned out that a longstanding member of the community, Paul Sladen, has a personal interest in typography. We noticed a marked uptick in the pace of bug triage when Paul got involved, and it was going so well we asked him to tackle it semi-professionally. The result has been really fast feedback to people making comments. I’d like to thank Paul for bringing that crucial stewardship to bear on the community engagement process, we would not have made it to the deadline without him.

We also had the benefit of a tool produced by Richard Lee and others in the design team, which lets people identify specific issues in the font, particularly as rendered in various web browsers on various platforms. fonttest.design.canonical.com is very cool: it lets you pick the characters, weight and size, takes a screenshot for you in most browsers, or helps you capture the essential details for the bug report. Fonts are software, but they are not software as we know it, Jim. So the tool helps us keep track of all the tricky details that might help debug a problem someone’s having.

A key open question, of course, was licensing. There are two obvious candidates, among quite a large field: the OFL, from SIL, and the GPLv3 with a font-specific clause added. Digging into this in more detail turned up a tricky situation: both approaches have issues which precluded us from adopting them immediately. We started speaking in some detail with Nicolas Spalinger of SIL, and Dave Crossland, who has done extensive analysis on the libre font process and dynamics. We offered to underwrite an SFLC review of the OFL, and SIL has expressed a willingness to participate in that, with a view to finding common ground that would bring Dave, ourselves, and many others under one common font licence, but we were running out of time. So we came to the compromise of an interim license, which you can find at bzr branch lp:ubuntu-font-licence While licence proliferation sucks, I’m optimistic we’ll converge in due course. James Vasile from the SFLC will help ensure the final result is wiser with the help of all the experience the SFLC gained in stewarding the GPLv3, and SIL and Dave will bring deep typographic industry insight.

Dalton Maag have started talking more widely about their experiences so far in the process. I was worried that they might be put off by the rowdy nature of open commentary, but I would credit them with a sterling constitution and thank them for the way they stepped up once the bug tracker really started to hum. There are few issues that are escalated which don’t get a rapid response and framing. Of course, there are differences of opinion, but in many cases genuine issues have been identified and handled. The team at DM have gotten into a great cadence of weekly iterations, and Paul has been ensuring that work makes it into the hands of Ubuntu users. As of today, *all* Maverick users have it installed by default (I believe this is true for Kubuntu as well, at least I answer questions in support of that goal).

What’s really interesting is that DM have said there is world-wide interest in the project. Many professional typographers are starting to think about open fonts. Now is the time to set a very high standard for what is achievable. There are hard questions to be answered about how the business of typography will evolve in the face of open and free type, but historically, those questions have best been answered by the bold: those who get involved, those who put themselves in the front line.

Going forward?

In due course, we’d like the Ubuntu font to reflect the full, extraordinary diversity of the Ubuntu community. We can’t do it all at once, and so we’re proposing a process for communities and cultures that feel part of the Ubuntu family to participate. If you want the Ubuntu font to speak your language, you need to do a few things to prepare for it. The hard, hard part is that you’ll need to find a qualified, local typographer who is interested in participating and in leading the design of your glyphs. You may need to find several, as we won’t necessarily embrace the first candidate. This is a serious matter: we welcome the crowdsourcing of bugs, glitches, rendering problems, hinting and kerning issues, but we want coherent, professional contributions on the core design. If that sounds exclusive: yes it is. Quality takes time, quality takes precedence. There are other fonts with lots of coverage, we have only one shot to get your glyphs done really beautifully then freeze them, metrically, for all time in the Ubuntu font.

The broader process looks like this.

First, you need to create a wiki page for your language / culture / glyphset (could be Klingon! Phoenician! Elvish ;-)) on wiki.ubuntu.com/UbuntuFont/Coverage. There, you need to document the glyph set you think is required, and any historical quirks that are peculiar to doing it well, such as OpenType features or alternative approaches.

Second, you need to file a bug on launchpad.net/ubuntu-font-family called “Ubuntu Font should support [Klingon]“. If you want, you can invite members of your community to note that they are affected by the bug. We’ll be looking for ways to prioritise communities for attention.

Third, you need to contact local typographers, and tell them about Ubuntu, open content, open typography. If they are still listening, you have just opened the door on the future for them and given them a big head start :-). They will need to be willing to contribute to the font. They will know how much work that will be. They won’t be paid to do it, unless the local community can find a way to raise the funds, but since there is a genuine sense of excitement in the air about open typography and this project in particular, we think you’ll find bold and insightful typographers who are keen to be part of it. Add their details to the wiki page, especially details of their typographic portfolio. Update the bug with that information.

The tools used for open font design are in a state of flux. There are some exceptional technical pieces, and some dark swampy bits too. Dalton Maag will be leading sessions at UDS with folks from the open typography community, with a view to producing what Dave Crossland described as a “lovely long list” (I’m paraphrasing) of bugs and suggestions. Be there if you want to get a professional typographers insight on the toolchain today and what might be possible in the future. All of the Ubuntu font sources are published, though the license does not require source to be published.

Nevertheless, the process for designing your community glyphs will likely involve a mix of free and proprietary tools, at least for the next months. We’ll ask DM to review the portfolios of candidate typographers, and make recommendations for who should be given the go-ahead to lead the work, language by language. Once core glyphs are designed, we’ll facilitate LoCo-based community feedback, much as we did for the main font. We want local Ubuntu members to have the strongest public voice in feedback to their typographer. And Canonical, with DM, will provide feedback aimed at keeping the whole consistent.

Once the glyph design process is wrapped, the typographer will lead hinting and kerning. That’s the tough, detailed part of the job, but essential for an interface font that will be used on screen, everywhere on screen, all the time. And at that point we’ll start automating feedback, using fonttest, as well as starting to integrate those glyphs into the main Ubuntu font. We’ll publish point releases to the main Ubuntu font, with major releases designating points where we update the set of “fixed and metrically frozen” glyphs, point releases denoting occasions where we add or update beta glyphs in the public test font.

In each point release, we’ll include perhaps one or two new glyph sets for beta testing. We’ll prioritize those communities who have followed the process, and have the most substantial community interest in testing.

Phew. If you got this far, you’re interested :-). This is going to be one of those things that lives a very long time. It will take a long time to get everybody represented. But we’re going to do it, together.