On 8/31/2012 11:10 AM, Andrew Deason wrote: > On Thu, 30 Aug 2012 14:04:14 -0700 > Russ Allbery <[email protected]> wrote: >> My broader point here is that these process problems that you perceive >> all come *directly* from a lack of time and resources. These are the >> kind of process problems that just don't happen in standards working >> groups where there are multiple people actively engaged, because >> people will constantly ping state or will just start taking over work >> that goes undone and driving it forward when other people run out of >> time. > > No, this comes from people not spending time on it. Nothing you have > said indicates _why_ they do not do that. People just avoid working on > this, which I believe is partially proven by the amount of other > non-critical AFS work that gets done, or the amount of time people spend > on having these arguments when the inevitable periodic flurry of emails > shows up.
In most "normal" standards processes, the majority of participants are paid to work on standards as part of their job description. In a prior e-mail in this thread I described the four methods by which resources are provided to this process: 1. Individual contributions. Most of us at one time or another have contributed in this capacity but doing so requires time in our personal lives. Speaking for myself, being married, having a dog and two nieces, parents that are getting older, and a company to run, I have much less personal time to devote. 2. End user organizations. Very few end user organizations devote resources to standardization. End user organizations want code written. I have never seen a development proposal request from an end user organization that includes writing test suites let alone funding of protocol standardization. Not in the IETF and not here. In fact, when a standardization requirement is raised as part of a development contract negotiation the end user organization frequently asks if there is an alternative method to address the problem. Standardization has proven itself to be open ended and end user organizations are unwilling to write a blank check. The organization is looking for a solution to an immediate problem in a fixed time frame with a fixed cost. 3. Support companies for the most part address the service requests of their clients. Support contracts typically do not include protocol standardization as an acceptable request but even if they did, few client organizations would request that the limited resources of the support contract be expended in that fashion. Support contracts do not generate enough profit to motivate the funding of standardization efforts. (See the open ended blank check in #2.) 4. Organizations that develop proprietary products based on the protocols that require standardization are the most likely contributors. The products that were in this category when the standardization process was started included IBM AFS, OpenAFS, Arla, kafs, and YFS. Of those, OpenAFS and YFS are the only ones left and YFSI has abandoned the concept of extending the AFS3 protocols. That leaves OpenAFS which itself has no dedicated resources. If OpenAFS had resources of its own to dedicate to the AFS3 standardization process, it would spend time developing protocol specifications as part of a process that prioritizes financial contributions into new features and releases. However, OpenAFS does not have resources to allocate of its own. There is no legal OpenAFS entity[1] to own intellectual property[2], to accept funds, or to spend funds. I'm simply not sure where you believe the time and energy to devote to AFS3 standardization is supposed to come from. My goals from the time that I began working on OpenAFS in 2003 until the present have been to meet the needs of the end user community. In 2003 I was single, had a stable income outside of AFS and had plenty of time to spend working on improving OpenAFS. At the time many organizations and individuals supported my efforts both via PayPal contributions and tequila. At one point my closet had so many bottles of Patron that I could have opened a taqueria. By 2007 the world changed. First of all, the low hanging fruit projects that OpenAFS required had all mostly been taken care of. The work that remained on the wish list were all large highly complex endeavors each of which would require tens or hundreds of thousands of dollars to complete. Many of the projects have inter-dependencies which make tackling them one at a time challenging. The appetite for funding this type of work simply did not exist among the broader OpenAFS user community. One large financial company funded completely or partially specific projects (instrumentation, demand attach file service, native windows client, ???) but in general there was little if any support from anywhere else. That is why in 2007 Your File System, Inc. was founded. If no one would take the risk to invest in the development of features and functionality they require ahead of their immediate needs, I would. YFSI tried for three years to develop its products by enhancing OpenAFS. YFSI obtained some grant funding. I personally invested hundreds of thousands of dollars. YFSI announced all of the features we were working on; placed all of our intermediate code on github for public review; submitted protocol documents for review. In the end, the lack of timely review made it impossible for us to continue along the same development path. If YFSI was ever to bring a product to market, it must find another way. Last year at the DESY Conference Hartmut and I were discussing the problems moving OSD forward when it occurred to me how both OSD and YFSI could move forward and avoid the road block that AFS3 standardization had become to the development of protocols that are compatible with AFS3 but are not themselves AFS3. In the last year both OSD and YFSI have made considerable progress. YFSI continues to devote resources to OpenAFS. It funds the gatekeepers, it contributes large quantities of code, and it identifies root cause and fixes serious bugs in OpenAFS when no one else is willing to do so. YFSI does these things for two reasons: 1. Derrick Brashear and I as Gatekeepers accepted a responsibility on behalf of the community and we are personally committed to fulfilling that responsibility to the best of our abilities. 2. It is in the best interest of YFSI and its current and future customers that OpenAFS continue to be a reliable option. To the extent that code that YFSI develops for its own products can also be of benefit to OpenAFS without compromising its ability to earn a reasonable return on investment for its investors, it has done so. At the present time, YFSI does not believe that there exists a compelling reason for it to drive forward the AFS3 standardization effort. Personally, I find it hard to believe that large end user organizations that have refused requests to fund the gatekeeper positions and have privately told me about internal decisions to decommission their AFS deployments by 2014 or 2015 are going to suddenly begin contributing resources to protocol standardization. In my opinion, the success of YFSI is the best hope that exists for continuing the AFS vision into the next decade. You asked _why_ people are not devoting time to AFS3 standardization. This is why those affiliated with YFSI are no longer trying very hard. Jeffrey Altman [1] Secure Endpoints Inc. has provided the legal cover (insurance, contracting, attorney fees, etc) for the Elders and the Committee when running workshops or negotiating with IBM, Microsoft, etc. [2] The source code is not owned by OpenAFS but by the individual contributors and licensed for use by others. Even the "OpenAFS" trademark is property of IBM.
signature.asc
Description: OpenPGP digital signature
