% Lines starting with % are comments and will be ignored
% comments may be treated as commands/actions/functions

% http://ospublish.constantvzw.org/conversation/even-when-you-are-done-you-are-not-done

% FS = Femke Snelting
% CL = Chris Lilley
% NM = Nicolas Malevé
% PH = Pierre Huyghebaert

% USED FOR NAME INDEXING
% HIDDENKEYWORDS: Lilley, Chris|Maléve, Nicolas|Huyghebaert, Pierre


% TITLE: Even when you are done, you are not done

% SCALEFONT: 1.3

At the **Libre Graphics Meeting 2008**,  OSP sat down with Chris Lilley on a small patch of grass in front of  the Technical University in Wroclaw, Poland. Warmed up by the early May sun, we talked about the way standards are made, how ‘specs’ influence  the work of designers, programmers and managers and how this process is  opening up to voices from outside the W3C.
Chris Lilley is trained as a biochemist, and specialised in the  application of biological computing. He has been involved with the World Wide Web Consortium since the 1990s, headed the Scalable Vector  Graphics (SVG) working group and currently looks after two W3C activity areas: graphics, including PNG, CGM, graphical quality, and fonts,  including font formats, delivery, and availability of font software.

%RESETFONT:
% BIGSKIP:

% NOWSPEAKING: FS
% ---------------
I would like to ask you about the way standards are made… I think there’s a relation between the way Free, Libre and Open Source software works, and how standards work. But I am particularly interested in your announcement in your talk today that you want to make the process of defining the SVG standard a public process?


% NOWSPEAKING: CL
% ---------------
Right. So, there’s a famous quote that says that standards are like sausages. Your enjoyment of them is improved by not knowing how they’re made.[^]{_Laws are like sausages. It’s better not to see them being made._ Otto von Bismarck, 1815–1898} And to some extent, depending on the standards body and depending on what you’re trying to standardize, the process can be very messy. If you were to describe W3C as a business proposition, it has got to fail. You’re taking companies who all have commercial interests, who are competing and you’re putting them in the same room and getting them to talk together and agree on something. Oddly, sometimes that works! You can sell them the idea that growing the market is more important and is going to get them more money.
The other way… is that you just make sure that you get the managers to sign, so that their engineers can come and discuss standards, and then you get the engineers to talk and the managers are out of the way. Engineers are much more forthcoming, because they are more interested in sharing stuff because engineers like to share what they’re doing, and talk on a technical level. The worst thing is to get the managers involved, and even worse is to get lawyers involved. W3C does actually have all those three in the process. _Shall we do this work or not_ is a managerial level that’s handled by the W3C advisory committee, and that’s where some people say _No, don’t work on that area_ or _We have patents_ or _This is a bad idea_ or whatever. But often it goes through and then the engineers basically talk about it.
Occasionally there will be patents disclosed, so the W3C also has a process for that. The first things are done are the ‘charters’. The charter says what the group is going to work on a broad scope. As soon as you’ve got your first draft, that further defines the scope, but it also triggers what it’s called an exclusion opportunity, which basically gives the companies I think ninety days to either declare that they have a specific patent and say what it’s number is and say that they exclude it, or not. And if they don’t, they’ve just given a royalty-free licence to whatever is needed to implement that spec. The interesting thing is that if they give the royalty-free licence they don’t have to say which patents they’re licencing. Other standards organizations build up a patent portfolio, and they list all these patents and they say what you have to licence. W3C doesn’t do that, unless they’ve excluded it which means you have to work around it or something like that. Based on what the spec says, all the patents that have been given, are given. The engineers don’t have to care. That’s the nice thing. The engineers can just work away, and unless someone waves a red flag, you just get on with it, and at the end of the day, it’s a royalty-free specification.


% NOWSPEAKING: FS
% ---------------
But if you look at the SVG standard, you could say that it’s been quite a bumpy road[^]{http://ospublish.constantvzw.org/news/whos-afraid-of-adobe-not-me-says-the-mozilla-foundation} … What kind of work do you need to do to make a successful standard?


% NOWSPEAKING: CL
% ---------------
Firstly, you need to agree on what you’re building, which isn’t always firm and sometimes it can change. For example, when SVG was started the idea was that it would be just static graphics. And also that it would be animated using scripts, because with dynamic HTML and whatever, this was ’98, we were like: _OK, we’re going to use scripting to do this._ But when we put it out for a first round of feedback, people were like _No! No, this is not good enough. We want to have something declarative. We don’t want to have to write a script every time we want something to move or change color._ Some of the feedback, from Macromedia for example was like _No, we don’t think it should have this facility,_ but it quickly became clear why they were saying that and what technology they would rather use instead for anything that moved or did anything useful… We basically said _That’s not a technical comment, that’s a marketing comment, and thank you very much._


% NOWSPEAKING: FS
% ---------------
Wait a second. How do you make a clear distinction between marketing and technical comments?


% NOWSPEAKING: CL
% ---------------
People can make proposals that say _We shouldn’t work on this, we shouldn’t work on that_, but they’re evaluated at a technical level. If it’s _Don’t do it like that because it’s going to break as follows, here I demonstrate it_ then that’s fine. If they’re like _Don’t do it because that competes with my proprietary product_ then it’s like _Thanks for the information, but we don’t actually care._ It’s not our problem to care about that. It’s your problem to care about that.
Part of it is sharing with the working group and getting the group to work together, which requires constant effort, but it’s no different from any sort of managerial or trust company type thing. There’s this sort of encouragement in it that at the end of the day you’re making the world a better place. You’re building a new thing and people will use it and whatever. And that is quite motivating. You need the motivation because it takes a lot longer than you think. You build the first spec and it looks pretty good and you publish it and you smooth it out a bit, put it out for comments and you get a ton of comments back. People say _If you combine this with this with this then that’s not going to work._ And you go _Is anyone really going to do that?_ But you still have to say what happens. The computer still has to know what happens even if they do that.
Ninety percent of the work is after the first draft, and it’s really polishing it down. In the W3C process, once you get to a certain level, you take it to what is euphemistically called the ‘last call’. This is a term we got from the IETF.[^]{The Internet Engineering Task Force, http://www.ietf.org/} It actually means ‘first call’ because you never have just one. It’s basically a formal round of comments. You log every single comment that’s been made, you respond to them all, people can make an official objection if you haven’t responded to the comment correctly etcetera. Then you publish a list of what changes you’ve made as a basis of that.


% NOWSPEAKING: FS
% ---------------
What part of the SVG standardization process would you like to make public?


% NOWSPEAKING: CL
% ---------------
The part that I just said has always been public. W3C publishes specifications on a regular basis, and these are always public and freely available. The comments are made in public and responded to in public. What hasn’t been public has been the internal discussions of the group. Sometimes it can take a long time if you’ve got a lot of comments to process or if there’s a lot of argumentation in the group: people not agreeing on the direction to go, it can take a while. From the outside it looks like nothing is happening. Some people like to follow this at a very detailed level, and blog about it, and _blablabla_. Overtime, more and more working groups have become public. The SVG group just recently got recharted and it’s now a public group. All of its minutes are public. We meet for ninety minutes twice a week on a telephone call. There’s an IRC log of that and the minutes are published from that, and that’s all public now.[^]{Scalable Vector Graphics (SVG) Feedback Page: http://www.w3.org/Graphics/SVG/feedback.html}


% NOWSPEAKING: FS
% ---------------
Could you describe such a ninety minute meeting for us?


% NOWSPEAKING: CL
% ---------------
There are two chairs. I used to be the chair for eight years or so, and then I stepped down. We’ve got two new chairs. One of them is Erik Dahlström from Opera, and one of them is Andrew Emmons from Bitflash. Both are SVG implementing companies. Opera on the desktop and mobile, and Bitflash is just on mobile. They will set out an agenda ahead of time and say _We will talk about the following issues._ We have an issue tracker, we have an action tracker which is also now public. They will be going through the actions of people saying _I’m done_ and discussing whether they’re actually done or not. Particular issues will be listed on the agenda to talk about and to have to agree on, and then if we agree on it and you have to change the spec as a result, someone will get an action to change that back to the spec. The spec is held into CVS so anyone in the working group can edit it and there is a commit log of changes. When anyone accidentally broke something or trampled onto someone else’s edit, or whatever - which does happen - or if it came as the result of a public comment, then there will be a response back saying we have changed the spec in the following way… _Is this acceptable? Does this answer your comment?_


% NOWSPEAKING: FS
% ---------------
How many people do take part in such a meeting?


% NOWSPEAKING: CL
% ---------------
In the working group itself there are about 20 members and about 8 or so who regularly turn up, every week for years. You know, you lose some people over time. They get all enthusiastic and after two years, when you are not done, they go off and do something else, which is human nature. But there have been people who have been going forever. That’s what you need actually in a spec, you need a lot of stamina to see it through. It is a long term process. Even when you are done, you are not done because you’ve got errata, you’ve got revisions, you’ve got requests for new functionalities to make it into the next version and so on.


% NOWSPEAKING: FS
% ---------------
On the one hand you could say every setting of a standard is a violent process, some organisation forcing a standard upon others, but the process you describe is entirely based on consensus.


% NOWSPEAKING: CL
% ---------------
There’s another good quote. Tim Berners Lee was asked why W3C works by consensus, rather than by voting and he said: *W3C is a consensus-based organisation because I say so, damn it*.[^]{Consensus is a core value of W3C. To promote consensus, the W3C process  requires Chairs to ensure that groups consider all legitimate views and  objections, and endeavor to resolve them, whether these views and  objections are expressed by the active participants of the group or by  others (e.g., another W3C group, a group in another organization, or the  general public). [@w3c:2005:policies] } That’s the Inventor of the Web, you know… (_laughs_) If you have something in a spec because 51% of the people thought it was a good idea, you don’t end up with a design, you end up with a bureaucratic type decision thing. So yes, the idea is to work by consensus. But consensus is defined as: ‘no articulated dissent’ so someone can say 'abstain' or whatever and that’s fine. But we don’t really do it on a voting basis, because if you do it like that, then you get people trying to make voting blocks and convince other people to vote their way… it is much better when it is done on the basis of a technical discussion, I mean… you either convince people or you don’t.


% NOWSPEAKING: FS