Re: What is Process Good For?

TL;DR: +1

16.12.2014, 12:05, "Kai Scheppe" <k.scheppe@t-online.de>:
> I find the comparison of ASF and W3C somewhat problematic.

I find it pretty stretched. ASF makes a suite of software products. (Where I work we use a lot of NGinx - maybe unsurprisingly).

They don't have, as far as I know, the competition regulators looking them over to check that their members are not behaving as a cartel. I'm not sure that the relationship of those involved mirrors closely the relationship between W3C members. As far as I know they do not have the mission to provide a standard for everyone - just a product for those who want it.
[...]
> I think it is good to look elsewhere for inspiration, but there must be
> a basis for comparison.

There are ways of learning lessons from very different organisations. I suspect there are a number of things we could learn from the ASF. Actually, we could also learn from the X Consortium, including the idea that we could close up shop.

But failing to note the differences is problematic, especially if they lead to missing important features that govern the interactions in the organisation and with its "environment". Which I think this comparison risks doing in a big way.
> [...]
> 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.

Indeed.

cheers

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

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 16 December 2014 10:50:20 UTC