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 20:52:41 UTC