[AFS3-std] Re: IBM will not re-license OpenAFS .xg files

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA1EA909164547C8B7662CA7D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8/31/2012 11:10 AM, Andrew Deason wrote:
> On Thu, 30 Aug 2012 14:04:14 -0700
> Russ Allbery <rra@stanford.edu> 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.
>=20
> 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 spen=
d
> 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=
=2E

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.


--------------enigA1EA909164547C8B7662CA7D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQQkfOAAoJENxm1CNJffh4PMcIALyfFF8LC0sblvAsy1ChZonP
/NICshQLS4HOu7E6+bh+HHb74rB8J1/GAAzt3j6IERNjg1G0GqG/cV+CVSAb/UFw
BO2mk2ilJpfA9FAg67gfWyVfaTs/x01X3DgA0g/COaa6CM3ZvvRllSNfe4inbEQM
99h3ywzm0pFaoxBnZuOMi5VBtf7MutKo0SKi2lMZy+Dp1G1ZfAgRrgO+vPv87jLo
4OtVwJQ89WPinjeutdrcD1JGq6VD+eYEMnRiLz5wdgFkgipjhpW/q1UzSizh46Vk
I1Awz6ZU9e0+2wmig2ndumLonTM/rGz/EF88dC6dMgiuANxFNAVfZ/a1w5vS8lE=
=GYGl
-----END PGP SIGNATURE-----

--------------enigA1EA909164547C8B7662CA7D--