Re: What is Process Good For?

On 12/15/2014 3:51 PM, Sam Ruby wrote:
> 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.

Fragmentation in open source is quite frequent.  Linux has many forks 
and many incompatibilities.  This might be a feature - a similar code 
base has different requirements in different systems. But fragmentation 
happens.

> 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.

If it is true that standards tend to fragment, some might view that as 
an important reason to discourage fragmentation.

>
> And the ASF has an equally strong position on the need for consensus.
>
> I'd encourage you to not dismiss this so readily:

I don't know what led you to believe that I was dismissive of anything.  
I noted that software and standards are different.  And I explained why 
fragmentation in standards is bad.  I don't consider that as being 
dismissive.

And, below I also itemized several items in which I documented how we 
have been liberalizing licenses in W3C.

> 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.

Bravo for that.  I think you know I support your efforts.

>
> 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?

I'm not sure I understand this question.

You have been proposing a workmode for URL and I have been encouraging 
you all the way in my remarks in this process CG.  Are you suggesting I 
should not be supporting this proposal?

>
>> 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:52:59 UTC