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

[Andrew Deason]

On Tue, 28 Aug 2012 17:28:46 -0700
Russ Allbery <rra@stanford.edu> wrote:

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

I don't see how this could possibly be true, regardless of the little
details of actual AFS development. "Not enough time" is a reason why we
don't get _everything_ done, but as to why any one particular "task X"
doesn't get done, the reason is that it is prioritized lower than
everything else. The only way that "Not enough time" would be the reason
for task X not getting completed is if task X could not be done even if
myself, Derrick, Simon, et al were working on nothing but task X full
time. There are no tasks where that is true, that I am aware of.

I think why I don't like your phrasing of this is that to me, it sounds
like saying "the _only_ way standards work will proceed is if there are
25 hours in a day, or more people are brought on to the process" (that
is, the only way is if more time/resources are obtained). Whereas my
opinion is that it is more true to say "standards work will proceed if
we work on it instead of working on other things A, B, and C" (that is,
if we reprioritize tasks).

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

So, from this, what I hear is that the reason standards don't get done
is that standards aren't as important as OpenAFS implementation tasks A,
B, and C. Whether or not that is "true" is the opinion of individual
developers, and is never well-defined or communicated or anything like
that. I also think that is becoming less and less true, since the lack
of ipv6 support, lack of strong crypto, and lack of reasonable wire
speed, and other features, are becoming blocking issues for an
increasing number of users.

I do not spend 100% of my time on AFS on things that absolutely must be
done within a certain timeframe, nor do I spend 100% of my time on
things SNA gets paid to do. At the very least, the remainder of that
certainly could go into standards work, and right now almost none of it
does. I cannot be the only person for which that is true.

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

In terms of what license released materials will be in, sure, that
doesn't seem likely to prevent anyone from working on this. However, any
uncertainty about licensing, document storage/archival locations, or the
general future of the body, etc etc, certainly can and will kill
motivation.

-- 
Andrew Deason
adeason@sinenomine.net