- From: Kai Scheppe <k.scheppe@t-online.de>
- Date: Tue, 16 Dec 2014 10:04:15 +0100
- To: public-w3process@w3.org
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