Re: What is Process Good For?

I find the comparison of ASF and W3C somewhat problematic.
I also find the new subject of this discussion troublesome.

ASF creates software. As with any product, if the public doesn't accept 
it, it will go away.
Another software, for example a fork, will take its place. End of 
story.  It is competition.

W3C is creating standards. Investments will be made at a root level, 
building large structures on this standard.
If the standard fails, the consequences are much more serious than if a 
software fails.
This is not competition.  It is supposed to be the bottom line which is 
non-negotiable by companies or individuals.

I think it is good to look elsewhere for inspiration, but there must be 
a basis for comparison.

A standard is supposed to be just that - the same for all.
As such consensus is vital, but the constraints have to be higher as 
well, to ensure broadest spectrum applicability.
That said, over-regulation is also a problem, will not solve anything 
and will undermine public support.

Constraints imply a controlled process that leads to the desired outcome 
- quality, compatibility, open.

I think this discussion would benefit from refocusing on the core 
issues, which I think are getting lost in a discussion that has little 
pragmatism remaining.

-- Kai



On 15.12.2014 23:52, Jeff Jaffe wrote:
>
> 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 Tuesday, 16 December 2014 09:04:53 UTC