[foaf-protocols] W3C WebID review

Henry Story henry.story at gmail.com
Fri Aug 20 23:09:34 CEST 2010

Of course I have to reply too, and if we go on like this we could spend the whole weekend on it. Below I have extracted the positive pieces of your comments. Perhaps we can work more on that from now on? :-)

On 20 Aug 2010, at 21:41, Doug Schepers wrote:
> [snip]
> To be clear, most groups at W3C try to use process as little as possible, other than the formal review process of progressively maturing documents (the "Recommendation Track").  We only need process when there is conflict, or ambiguity about licensing (which is also tied into the Rec Track).  But as you add stakeholders, more process is needed, it seems, to resolve small and large conflicts.
> As a side note, most W3C Working Groups start off very loose and easy, with rapid iterations of specs and ideas and very little process, and as those specs mature, and get wider attention, more process comes into play.  So, really, it's not very different from these sorts of community-organized efforts (though there is a formal step at the outset to decide amongst the W3C Team and Membership if there is value in starting the work in the first place, for resource allocation purposed).

Very good. 

But as you explain below, implementations matter. Two years ago the user interface for creating a WebID was: the command line to make a certificate, ftp to publish it to your web site, and vi to edit your XML.

Now it's a click of a button to create the WeBId, and normal html forms to enter your detail. We still don't have anything that looks quite like Facebook, but some people here are working on that. 

> [snip]
> You might say that I don't have to respond to these emails... except, unfortunately, that's not the reality of the situation.  If I hadn't responded, suddenly it's on some public list somewhere that W3C is holding "secret meetings" and is refusing to talk to the community and is trying to take over WebID or is ignoring WebID or whatever.  It's the whole "have you stopped beating your wife" conundrum; it costs you very little to leave a wrong impression (whether you mean to or not), and costs me much more to address the issue.  And then, suddenly, I'm seen as speaking for the W3C as a whole, which is also the wrong idea.  You see my dilemma?

Yes, but we need to curtail this process if we are not to spend the weekend wrangling with shadows.

To help you get a bit of a better feel, this group I think is full of W3C fans. We are all using the RDF toolkit, XML, XHTML and javascript even. We just intend the best for the W3C. That's why I wanted to let people know the protocol was being discussed there. 

> [snip]
> I could go into detail about what makes an idea more or less likely to be taken up by W3C, but that would be a long conversations.  The short version is: people, and momentum.
> Individuals are what make or break a technology.  Without the right person at the right time applying just the right amount of time and focus on something, it will almost certainly peter out and fade away. Obviously, it takes many such individuals, each with their role.  As Lucille Ball said, "If you want something done, ask a busy person to do it."  You can't just go to W3C, tell one person an idea, and expect it to be immediately taken up; you have to find the right person to overcome the natural momentum of other things that are being done.
> Which leads to momentum.  W3C is more likely to pick up work that already has a spec and/or implementations, because it's more likely to have a successful outcome; and in fact, W3C is more likely  to pick up work that has competing, conflicting implementations, because there's more need for standardization.  It's also more likely to pick up work that large companies are behind, even if there's only one company doing it; on the surface, that may seem unfair, and may seem like favoritism toward large companies, but in fact, that's not the motivation... the metric is that if some idea has already been through the ringer at a large company, it's already been vetted by a fairly sizeable, critical audience, and that the company has decided to put resources behind it, so there is a higher chance of success... and a larger risk to the community if that company doesn't get all the details right, because large installation bases tend to spread mistake irrevocably.  Obviously, that heuristic doesn't always work (big companies can also have stinker ideas, or good ideas spoiled by overthought, just like the rest of us), so we need people to assess the soundness of the idea and the benefits of standardizing it.  That's where it comes back to individuals.
> Where do community projects like this come into it that dynamic? Clearly, the larger and more cohesive the community, the greater the momentum.  But without a central driving force, there's also a wider spread of the odds.  A dedicated individual can often have greater impact, because they are often working out of passion, not just because they are paid to (frequently, they aren't paid at all); they might make a really great implementation that pushes the idea over the top, and small communities have a "street cred" that large companies usually can't evoke; so, a good idea might spread more readily.  But in the long haul, or without those initial firebrands, the project might sizzle out, and lose its momentum.  From the W3C perspective, probably the optimal time to get involved (if we do so at all) is just before the peak of the momentum, just before the project really makes it (or fails); that's where W3C can help boost the momentum to reach critical mass, and also to help ensure that the efforts stay unified and interoperable.
> (Yes, that was the short version.)

Yes, going to the W3C two years ago would have been way too early. Now is the right time, because the Social Web  is growing in momentum and political significance by the day. The Social Web XG with whom I have been working for the past two years will have its report out soon!

>> There was no invitation. I told people this was probably a private
>> meeting and that the person to make such a decision was Doug. Perhaps
>> indeed I could have gone the other way and first asked Doug.
> The outcome of that seems obvious to me.  Was it not predictable to you?

No, not really. Don't think we had an issue like this on this list before. But then we never presented our work to a standards body, which tends to be a more political situation than others, what with competing groups wanting to fight it out.

> [snip]
>> - We worked in public in order to discover the best way to create
>> privacy. - The W3C group, a public standards body of the highest
>> quality, requires privacy to reduce the workload of its members. - In
>> the shadows unexpressed issues lurk - for fear of making them
>> public?
> It's not clear to me what you're saying here, but it sounds very scary.

It is not scary. I am just pointing out that one needs privacy in order to think, and the complex issues relating to privacy and publicity. That sometimes it is good to get ideas out in the open, because otherwise weird fears hang out in shadows. There is a contradiction - a tension - between the need for privacy and publicity. Which furthermore this email thread is a testament to. And indeed as you point out below nothing is as easy as it seems:

> For what it's worth, W3C used to work more privately, but over the past few years, it's become much more public in how it conducts its technical work; that may *seem* like it increases the workload, but I would argue that it offsets the workload from the future to the present, thus improving the leverage.  Bad implementations because of mistakes in specs cost the community a disproportionate amount of work, and ultimately force the groups who've produced successful (but flawed) specs to make a lot of difficult errata and corrections (when the mistake can be corrected at all), so addressing potential mistakes earlier in the standards process, with wide community review, actually saves everyone time... even the working group.  (Note: it's still frustrating as hell for the WG, don't get me wrong.)

Yes, I worked on the Atom syntax spec and I know how frustrating standards process are. But it's a great exercise in understanding other points of view. 

We now have quite a few implementations of WebID (foaf+ssl), in every programming language. We are looking to grow the implementations we have and make them more interoperable, but also to create more vivid examples of this in use.

The standards process is needed not so much for us, but because we need to polish a lot of little details now, and without a good process it is difficult to do it. 

> Now, aren't you sorry you brought me into this?  I've taken your nice clean technical discussions and muddied them with icky standards gunk (believe me, it doesn't come off in the wash), and I'd guess to no-one's benefit. :)

I have a somewhat biological view of standards: they grow and as things in life they can be icky. We have been growing the community here slowly and continuously for a time. It's great every time a new person joins, and every time a new software links up with the old we all gain in the process. But it takes time explaining things. Yet every time we get a new piece working things are easier to explain. I bet in a few years it will be so easy and so obvious, that sadly nobody will even understand what there was to invent here. We'll be like the poor guy trying to explain to someone that he invented the Post it note - or the web for that matter ;-)

We need to develop tools to help test people's implementations, develop new standards for making friends, access control, privacy, and much more. WebId is just the first step in what is going to be the Social Web. 

But perhaps that will become clear on Thursday if I am given a bit of time to speak.


> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

More information about the foaf-protocols mailing list