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

[Russ Allbery]

Andrew Deason <adeason@sinenomine.net> writes:
> Russ Allbery <rra@stanford.edu> wrote:

>> This issue has never been the serious blocker for standards work around
>> AFS.  That blocker has always been the same thing that blocks most
>> things about AFS: simple lack of time among the people who are
>> currently able to do the work.

> "Not enough time/resources" isn't really a reason; not on its own. The
> people able to do this work have plenty of time, but they just choose to
> spend it doing other things.

There is considerably more that needs to happen with AFS than there are
currently time and resources available to do it.  Standardization is one
of those things.  There are many.  The primary reason why any specific
thing does not get done in AFS, whether that be major new functionality
work or protocol specification work, is "not enough time/resources."

Now, with that as a given, the scarce resources can, of course, be
allocated in various different ways.  More of them could be allocated to
protocol work than functionality work, for example.  But that's not
actually as clear-cut as it sounds.  Some types of work can't just happen
eventually, when someone gets around to it.  There is quite a lot of
development work that needs to either happen within a particular time
frame or will not happen at all, because the resources simply won't be
spent on that problem unless the result can be achieved within a
particular time period.

Standardization is one of the steps that is skipped in order to meet those
other, external requirements, which in turn are prerequisites for having
the resources available.

So, no, I don't think I agree.  I believe lack of time and resources is
the primary reason why standardization work isn't happening.  It's very
similar to why the documentation is badly out-of-date (although better
than it was): people had enough time to either implement new functionality
that they needed, or write documentation for it, but not do both, so the
repeated decision was made to implement new functionality without
documentation (since functionality without documentation is somewhat
useful and documentation without functionality is not useful at all).

> Another is a lack of faith that anybody else even remotely cares about
> what is being done, and a sense of general confusion about the state of
> things. This is probably especially true for those of us that do not
> have experience with working with protocol standardization, since we
> have no idea what a properly working process even looks like. A
> document/task will go a year without any noticeable movement... and
> nothing happens.

Someone needs to drive the discussion through to completion and publish a
document.  That's another lack of time and resources thing.  (Note the
"currently able to do the work" part; sometimes the problem is that the
people who know how to do things like push a standards document through to
completion are thin on the ground and are a tiny subset of the people who
are interested in the standards work.)

Anyway, the point that I'm trying to get at here is that the licensing
question isn't going to be the thing that prevents AFS from having
standards documents.  Nothing about the license situation prevents people
from stepping up to do the work.  The path forward is relatively simple,
just difficult: decide that standardization is important, write standards
documents, read and review standards documents, revise standards
documents, and then publish them somewhere if they've reached consensus.
The last could be any web site anywhere or even just something on Github.

But writing documentation is hard and takes a lot of time, and is not
generally the piece of the puzzle that most of us are actually paid to do.

That task of driving things through to completion, which is probably the
best way to view the job of working group chair, is one of the things I do
for Debian with Debian's standards documentation.  If you want a feel for
what that process looks like in a completely non-IETF world, you can see
the current categorized backlog at:

    http://bugs.debian.org/debian-policy

There's stuff that's been stalled for ten years.  This is relatively
normal for standards work.  The things people care about move faster than
the things that are edge cases.  But I could make substantial forward
progress on any one bug there any time I wanted by just sitting down and
putting hours into it.  The process moves as fast as people have time and
resources available to push it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>