[2723] in Release_7.7_team
IBM AFS action plan.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Fri Apr 27 17:28:27 2001
Message-ID: <YuuSFsFz0001IkUUxi@mit.edu>
Date: Fri, 27 Apr 2001 21:28:24 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: jdb@MIT.EDU, pbh@MIT.EDU, vkumar@MIT.EDU, longpd@MIT.EDU,
afs-contacts@MIT.EDU
CC: ramfosr@us.ibm.com, gerchak@us.ibm.com, release-team@MIT.EDU,
alexp@MIT.EDU, rferrara@MIT.EDU
Here is my understanding of the summary of where we stand with AFS
support, and the plan to move forward from the IBM conference call I
just completed:
Summary:
The proposed plan:
1. Purchase support from IBM
2. Do not pursue an IBM Subscription agreement
3. Actively pursue the offer of Gary Gerchak to continue to have a
source code license for AFS.
4. Stick with IBM AFS 3.6 patches 1 on the Windows 2000 side.
5. Go to Open AFS on the Linux side.
6. Monitor the situation to decide which AFS to run on Servers, Solaris
clients, and SGI clients.
7. Recognize in our other projects that IBM is not as responsive and
collaborative a vendor as we would hope.
---- Detail and rationale ----
1. Purchase support from IBM because it entitles us to continued contact
with IBM, and to patch releases of AFS 3.6. This is simply prudent. It
maintains our ability to deploy working AFS 3.6 for Windows 2000, and
holds out the possiblity that there will be a useful IBM AFS for Red Hat
7.1 with the 2.4 kernel.
2. Do not pursue an IBM Subscription agreement because there seems to be
no major release of IBM AFS planned, and so the possible benefit of
receiving such a release at reduce cost are not expected to be realized.
3. Actively pursue the offer of Gary Gerchak to continue to have a
source code license for AFS. This will enable us to maintain our
present service levels and to continue to have the rich communication
with the IBM service engineers we have had in the past.
4. Stick with IBM AFS 3.6 patches 1 on the Windows 2000 side. As said
above, IBM is unwilling to resynchronize with Open AFS here.
RISKS:
I expect getting source code will continue to be more difficult over time.
I expect the support process will become more cumbersome over time.
I expect the development process will become less responsive over time.
BENEFITS:
It keeps us running without significant work on our part.
ALTERNATIVES:
Redo our work on getting AFS to work for Windows 2000 for the Open AFS
community. This would gain us the benefit of perpetual source access
and an extremely responsive development and debugging community. At
this time it is my assessment that this alternative is too expensive for
us.
5. Go to Open AFS on the Linux side.
RISKS:
Open AFS may prove less reliable than we have historically offered.
Without the testing we've historically gotten from IBM there is a
greater probability we will discover problems after going live.
MITIGATION:
We have historically been as good or better than Transarc at isolating
faults and fixing them. Getting the company's support organization out
of our way will reduce our costs and increase our effectiveness here. I
expect the IBM development and support process will become more
cumbersome over time. By maintaining our support relationship, we also
leave open the possiblity that an IBM AFS patch release for Red Hat
Linux 7.1 with the 2.2 kernel will arrive in time and with sufficient
robustness to be worthwhile.
BENEFITS:
We get the Linux port of Athena running in a timely manner.
We explore the Open AFS community and compare the costs and
responsiveness of working with it to the historical norms of working
with Transarc/IBM.
COSTS:
We will need to put resources behind integrating building and testing.
(Some of these costs have been being borne in our work to validate
Transarc output. We had been in the process of dismantling this and
will just reverse our course.)
ALTERNATIVES:
Wait for an IBM AFS patch release that Red Hat Linux 7.1 with the 2.2
kernel. Historically this sort of thing has been very stressful for all
parties concerned. Transarc never amended their development process in
response to our input. So the costs in time and stress are the same as
every year.
6. Monitor the situation to decide which AFS to run on Servers, Solaris
clients, and SGI clients.
At the present time, there is no pressing need to switch off IBM AFS
under IRIX or Solaris. Solaris is our major server platform, so a
switch there would occur AFTER a period of client testing. Depending on
the observed reliability of the code, and the responsiveness of the
community we should take appropriate steps either to continue to upgrade
to subsequent versions of IBM AFS or to switch to Open AFS.
7. Recognize in our other projects that IBM is not as responsive and
collaborative a vendor as we would hope.
Below is a section "Commentary for IBM" in which I lay out the problems
with the relationship that are going to drive us over time further and
further away from IBM. Having seen this scenario play out with the
Project Athena IBM involvement, I have no hope that we will be heard
this time either. We should take this lesson ourselves: IBM never
learned what we hoped they had learned from seeing Linux go where
Project Athena could have taken IBM ten years sooner and for a billion
dollars less. IBM insists on spending millions of dollars on projects
that it ignores until it decides to spend billions reproducing what it
should have learned from the less costly effort.
Particularly in 1 to 1 computing: IBM seems still, at heart, the big,
policy driven dinosaur we saw in Project Athena. BEWARE as we consider
hitching our laptop endeavors to a supposedly responsive Linux-aware
IBM. The situation with the AFS busines model shows that the notion of
collaboration may not have taken sufficient hold in the IBM culture.
---- Details from conference call ----
Good news items:
It is clear that the "Subscription coverage program" would be
inappropriate for MIT. It is expensive, and is predicated on the
assumption that IBM would come out with a major AFS release of
significant value and at significant increased cost. The program was
originally offered when IBM planned to produce major AFS releases, and
currently IBM has no such plans.
The dollar cost for being able to receive support and patch releases for
IBM AFS has dropped. It looks like we would pay $6280 for 24x7 support
and 6 callers. This is a good deal dollar-wise.
It was mentioned that an updated Linux port is in progress.
Bad news items:
IBM was initially unwilling to continue to provide sources for patch
releases. Gary Gerchack has the action item to pursue obtaining a
license and price to continue to offer this to MIT. I am concerned
that, as time goes on, it will be progressively more difficult for us to
obtain source for IBM AFS.
The support process IBM wants us to follow adds another layer of front
line support that we have to go through before we get access to AFS
engineers. I pointed out that MIT traditionally preferrs more direct
access to engineers, and that this decreased the responsiveness of the
support system for us.
IBM is currently not interested in working more closely with the Open
AFS process to make testing easier.
IBM is currently not interested in disclosing to the Open AFS community
the deltas between AFS 3.6 and AFS 3.6 patches 1 that we rely upon for
reliable Windows 2000 operation.
IBM is currently not interested in changing their development process to
more quickly produce ports to new platforms. (I'd suggested a program
of more frequent sharing of code between Open AFS and IBM.)
---- Commentary for IBM ----
At the present time, the IBM models of support, porting, and development
are extremely unattractive to us.
We are being asked to go through more layers of buraucracy to reach
development engineers, even though historically we have given more
benefits than we cost.
We are faced with the prospect of progressively greater reluctance on
IBM's part to keep us in sync with source code even in the light of
clearly identified benefits.
We are unable to interest IBM in a model of collaboration with the Open
AFS community that serves to benefit MIT from greater responsiveness to
our requirements, clearer lines of communication, and which benefits IBM
by taking advantage of new developments from the community. The cost to
IBM is a single source delta with a product line that has no major
releases planned, and the disclosure of an ugly but historically
valuable test suite.
I respectfully submit that it is in IBM's long term interest to pursue
the business model of more frequent, two way collaboration with the Open
AFS community. The present business model will only serve to drive
customers away from an insufficiently responsive product and service
organization, and continue to reinforce the stereotype that IBM is more
interested in maintaining the historical, rigid, IBM policies than in
collaborating with customers. The good will benefit of the initial
sponsorship of Open AFS is at risk here.
