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

[Andrew Deason]

On Wed, 29 Aug 2012 12:48:17 -0600
Kim Kimball <dhk@ccre.com> wrote:

> I hear that "we can't" ... "we must" 
> 
> Perhaps we can evaluate this:  "... or are desperately-needed
> functionality that can't afford to be blocked on standardization. "
> 
> What is the desperately needed functionality, and for each such item
> what is the desperate need?

"Desparately needed" is defined extremely differently according to
different organizations, and can be conflicting. It is difficult for me
to even begin to answer that question for myself, let alone arrive at
some agreement between everyone.

> If OpenAFS could deprioritize some number of functionality related
> tasks, would resources devoted to those tasks really be reallocated to
> standardization?  
> 
> Can OpenAFS currently identify people who would gladly work on
> standardization but are currently blocked on functionality tasks?

These are good questions. I have another one. Should the standards group
try to prioritize and limit the scope of existing standards work? In
thinking about this, I wondered about the possibility of trying to get
everyone to work on _one_ document until some consensus point is
reached, and only then are new documents even proposed. Normally I would
think that doing something like that is prohibitively slow, but I find
it hard to believe that anyone involved in the standards process right
now would be significantly slowed down by that.

I mean, given the low level of activity, we are spread pretty darn thin.

> What do we need to know, factually?  What resources can OpenAFS count
> on?  Does/Can OpenAFS agree on priorities?  Who's working on what
> right now?  If tasks were reprioritized,  who would actually volunteer
> to work on standards tasks?  Is it possible to list/name
> tasks/priorities/resources?

If you're talking about OpenAFS development, it's not nearly coordinated
enough at the moment to answer those questions (not that it needs to be;
I don't think large open source projects generally are). If you restrict
this to standards-related work, then maybe that is feasible.

-- 
Andrew Deason
adeason@sinenomine.net