RE: What is Process Good For?

NOT speaking for Microsoft here...

Sam wrote:
> All I will say is that I personally would be much happier working with what amounts to an "Apache Standard Organization"
>  than I am currently with the W3C 

I'm not ready to go quite that far, but  I strongly agree W3C should take a close look at what works for ASF and consider adopting or adapting those features  for W3C.  Yes there are differences in the missions and cultures of the organizations, but there are a lot of similar problems that Apache addresses in an interesting way.  Specifically:

- Trademark policy http://apache.org/foundation/marks/ .  In a world where CC0 or liberal copyright licenses are the norm, Apache's approach of insisting that projects have unique names, trademarking those names, and taking action when necessary to enforce the trademarks is worth careful consideration by W3C. For example, there are a lot of distributed storage and processing frameworks out there, but only one Apache Hadoop.  One can fork Hadoop, but you'll get trouble if you call your fork "Hadoop++" or "Living Hadoop" or whatever.   W3C's approach has been the opposite -- use extremely generic names, asserting copyright over the text of W3C specs, but doing very little to enforce the copyrights.   We can't turn back the clock, but GOING FORWARD we could ask WGs to come up with more distinctive names and at least try selectively trademarking them to reduce confusion between W3C Recommendations and derivative works, or forks of input documents.   

- Software License http://www.apache.org/licenses/LICENSE-2.0.html - As I understand it, this was drafted to cover both code and documentation, and it allows forking, encourages attribution, AND is compatible with the Mozilla license  https://www.mozilla.org/MPL/license-policy.html.  In short it may hit a sweet spot that W3C has been struggling to find for a couple of years now.

- Lazy Consensus http://community.apache.org/committers/lazyConsensus.html "You just assume you have the communities support unless someone says otherwise." Perhaps this is not unlike WHATWG, but Apache has more checks and balances, specially a mechanism for expressing and reconciling objections to an arbitrary decision. Maybe "W3C Consensus" is still valuable for Recommendations, but I suspect we would improve the timeliness and quality of specs by using Lazy Consensus rather than cumbersome and inconclusive CfCs as the mechanism for driving drafts specs to maturity.

- Meritocracy http://theapacheway.com/ - "Those that have proven they can do, get to do". This might be the hardest to reconcile with W3C in the short term, but I have a hard time believing  anyone but Tim Berners-Lee would have the build-in credibility needed to be a Director as W3C defines that role today.  It's time to think creatively how to balance the diverse needs of the W3C membership and the reality that it takes specialized expertise to have an informed opinion on the matters that the Director currently must decide on. 

> Key concepts: Community, Merit, Openness, Pragmatism, and Charity.  
Sam, would you care to elaborate on any of these I didn't mention?

-----Original Message-----
From: Sam Ruby [mailto:rubys@intertwingly.net] 
Sent: Monday, December 15, 2014 12:52 PM
To: Jeff Jaffe; David Singer
Cc: public-w3process@w3.org
Subject: Re: What is Process Good For?

On 12/15/2014 03:03 PM, Jeff Jaffe wrote:
>
> On 12/15/2014 2:32 PM, Sam Ruby wrote:
>> On 12/15/2014 01:43 PM, David Singer wrote:
>>>
>>>> On Dec 14, 2014, at 8:27 , Sam Ruby <rubys@intertwingly.net>
>>>> wrote:
>>>>
>>>> On 12/14/2014 09:41 AM, Léonie Watson wrote:
>>>>> Chaals wrote: "In my own experience on the AB, in principle people 
>>>>> could read the mailing list and minutes for the last few years to 
>>>>> find out what had already been discussed before they joined, but 
>>>>> it seems rare that it actually happens, resulting in revisiting 
>>>>> things that don't need to be rehashed (as well as revisiting 
>>>>> questions that are due to be revisited - it isn't as if the 
>>>>> answers to questions that were given from 5-10 years ago should 
>>>>> never be re-opened)."
>>>>>
>>>>> I can't speak for TAG specifically, but generally with these 
>>>>> things it's helpful to have some work-mode continuity too.
>>>>> Otherwise there tends to be a period with minimal productivity 
>>>>> whilst the new group figures out its approach. It's difficult to 
>>>>> discover how things are done just by reading minutes/mailing 
>>>>> lists, no matter how diligent someone is.
>>>>
>>>> I don't think that there is any question that continuity is 
>>>> desirable.
>>>>
>>>> I will simply note that in the W3C there seems to be an 
>>>> institutional propensity to define process with the intent of 
>>>> preventing undesirable things from happening.
>>>
>>> This is an aside to the current discussion:
>>
>> OK, new subject is therefore in order.
>>
>>> I actually think that handling difficulty, preventing undesirable 
>>> things, and so on, is the main point of a process;  to help guide 
>>> you when life gets tough.  Is this OK? What are we supposed to do? 
>>> and so on.
>>>
>>> No-one needs process when everyone is in agreement with what's going 
>>> on; and no-one likes having to apply a point of principle once it's 
>>> in the course of being violated - you want to have settled the 
>>> principle 'in the abstract' before you hit an 'instance', if at all 
>>> possible.
>>>
>>> Problems arise when the process gets in the way, of course.
>>
>> Again, I'll simply note that you and others are proving my point: in 
>> the W3C there seems to be an institutional propensity to define 
>> process with the intent of preventing undesirable things from happening.
>>
>> Overall, I must say that I'm much happier with the ASF.  We do 
>> document rules for external interaction, but for internal interaction:
>> not quite so much.
>
> It is interesting that you compare to ASF - a foundation whose defined 
> purpose is open source software projects.
>
> W3C, does not define its mission in terms of open source.  Its mission 
> is defined with respect to leading the Web.  Its focus is on standards 
> rather than software.  It is harder to say for standards "take my work 
> and do with it as you like" because that perspective leads towards 
> fragmentation rather than standardization.  The OpenStand principles 
> focus more on consensus (which is hard, but important) rather than 
> "take my work and do with it as you like".

And yet, the ASF is viewed by many as a leader.  One that many projects want to join.  And also one that many other organizations have copied.

And while fragmentations is a theoretical possibility, it is one that rarely occurs.  Can you name a fork of the Apache Web Server?  In fact, it has been my observation that there has is a greater fragmentation around standards (*cough* URI *cough* IRI *cough* URL *cough*) than there is around software.

And the ASF has an equally strong position on the need for consensus.

I'd encourage you to not dismiss this so readily: as someone who has been immersed in both over a long period of time: I think that there is a greater similarity than you might suspect.

Note: I'm realistic.  I don't expect that the W3C will change.  All I will say is that I personally would be much happier working with what amounts to an "Apache Standard Organization" than I am currently with the W3C (or WHATWG, for that matter).  Am I'm personally doing what I can to nudge both of those to (and, WebPlatform.org, a.k.a. webspecs) in that general direction.

Meanwhile, I will caution you: if you continue to attempt to keep a tight grip on the standards you have through onerous Invited Expert terms and conditions and Document Licenses, what I suspect is that you will increasingly find that standards will be defined -- WITH CONSENSUS! 
-- elsewhere.  And the W3C will be reduced to belatedly giving their stamp of approval.

In fact, an instance of this is exactly what I briefed the AB on earlier
today:

https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface

Is that leadership?

> We also love open source.  We have practices that (I believe) are 
> appreciated by the open source community such as removing patent 
> encumbrances.  We've recently introduced permissive licenses (CC-BY) 
> for some specifications.  We are currently polling the AC with a 
> proposed general document license for W3C which would make re-use much 
> easier and clearer - as long as it is not aimed on confusing the 
> industry with derivative specifications.

I must say that I find that choosing a license that the authors of the GPL, and the authors of the MPL, have explicitly rejected is hard to reconcile with "love open source".

I also believe that there is a strong, complementary relationship between open standards and open source.  I will say that in my career at IBM, we have actively pursued both simultaneously as their goals are complimentary.

This was done with XML (standard at the W3C, and IBM donated an open source implementation to the ASF).  This was done with Web Services (again, standardized at the W3C, IBM donated an open source implementation to the ASF).  This pattern has been repeated with other combinations of standards and open source organizations.

In general, it is worth recognizing the best you can hope for with open standards and open source is eliminating excuses not to be compliant. 
SOAP is actually an example of how that often isn't sufficient (I say that as a reformed WebServices advocate).

I've internalized this.  If you examine my work on URLs, what I have been focusing on is eliminating any excuse anybody might have to not participate.  Anybody, whether you are are the IETF, WHATWG, W3C, or a company that participates in one or more of the above.

Key concepts: Community, Merit, Openness, Pragmatism, and Charity.  If these concepts seem appealing, I encourage you to dive into the next level of detail on each here: http://theapacheway.com/

>> I'd sum up the general philosophy in this way: in matters involving 
>> collaboration, what matters is that the people involved have common 
>> goals.  If they do have common goals, rules aren't necessary.  If 
>> they don't have common goals, rules don't help.
>>
>> Part of what makes this work is a liberal license.  If you don't want 
>> to work with me?  That's fine.  Take my work and do with it as you 
>> like...  Our few rules are structured around ensuring that projects 
>> that nominally are working together actually ARE working together.
>>
>> - Sam Ruby

- Sam Ruby

Received on Monday, 15 December 2014 22:14:41 UTC