[OpenAFS] the future

[Jeffrey Altman]

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

On 9/30/2012 3:34 PM, Gary Gatling wrote:
>=20
> Could government or corporate grants be a way to raise funding for
> development of new features or programmers in openafs? Especially since=

> openafs is open source software and everyone benefits? I'm sorry if thi=
s
> is a stupid question...

Gary,

Its not a stupid question.  YFSI did receive U.S. Government SBIR grant
funding.  Such funding is required to be used for the establishment of a
commercial product but is insufficient by itself to bring a product to
market.

Corporate grants are nearly impossible to obtain for software
development.  There is no justification for using the granting process
when software development contract payments are 100% deductible as a
business expense.   Software development contracts are not hard to
obtain when the cost is below $10,000.  Unfortunately, there are very
few software development projects that can be accomplished in two or
three developer weeks.

Using rxgk as an example.  The original draft of the security class was
imported into the OpenAFS source tree in August 2004.  An effort was
made in 2005 to move ahead with it but as reported to Troy on the
openafs-devel list in May 2006, there were significant numbers of bugs
in 1.4.0 release that had to be fixed for 1.4.1.   The volunteer cycles
to work on rxgk was lost to that effort.

In January 2007 an "rxgk" specific week long hackathon was held at
Stockholm University.  Significant progress was made in scoping out the
protocol requirements, the operational deployment requirements, and the
paths for upgrading from rxkad to rxgk.  The second draft implementation
of rxgk was created during this hackathon and committed to Arla.
However, there was no functional code nor was there a complete protocol
specification.

The YFS rxgk implementation and protocol specification is a third design
which differs in significant ways from the outcome of the Stockholm
University hackathon.  The differences are the result of in-depth
protocol review and implementation experience.  Creating the rxgk
security class itself was the smallest part of the work.  The bigger
challenge is the integration of rxgk into the source tree.  In order to
accomplish it all services must be converted to pthreads since there is
no LWP GSS-API implementation.  References to rxkad had to be isolated.
 The rx security class interfaces had to be turned into opaques.  New
credential management interfaces had to be developed.  Library
management had to be converted to libtool.  The DES crypto
implementation was replaced by an RFC3961 Crypto Framework derived from
a refactored Heimdal.  Many other things as well.  The vast majority of
this is work is already upstream but the point I am trying to make is
that the commitment to implementing rxgk was a commitment to writing an
open ended check.

Opened ended checks are required for many OpenAFS projects.  The Windows
native redirector is perfect example.  The proof of concept
implementation was $280,000.  The first production version shipped as
1.7.1 required well over $1 million.  The next major revision will
probably cost another $500,000.

Most of the OpenAFS feature enhancements that are desired require
substantial open ended commitments.  Corporate development contracts and
open ended research and development are simply not a good match.

Jeffrey Altman



--------------enigAFD86A410AF5CD28600C7D7F
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)

iQEcBAEBAgAGBQJQamAsAAoJENxm1CNJffh4D4kIAIRg7xJ8EsAE8e+pRMcdE9hq
HMhGuObiwg2B3YCzKgBBFuPxyg3ku0n24IX2AxG5gm0mBSjKEYuVq/2khqRuFZBq
OQBCPqiNqFxnZMzcS0u3CLSbXToJk2PRqZnt14gULIQuTCC4JMouGDqu6t6WdBzm
5Qs1m6XcU/trdBcLbpvwmpIZR0SpHNQLuvoNPLx4wsQ8ngrcs4AM7Uw1Y7kGRgs+
pckSezfpZaqsE3SRX+0wDTKkRPN7VjxjeaHENFVIXpQWlwc0nbPeGUGrNu4C6lwl
hRCRCYIC+WdZV/20jvQVl78OLwISnbYlq3a7TUixpnd8Tey7lYhWV2PRhIpUlbo=
=DEIV
-----END PGP SIGNATURE-----

--------------enigAFD86A410AF5CD28600C7D7F--