FYI: Lessons from Kai Wu at ArsDigita

Howdy.  Below is an email that Kai Wu, a former engineering manager and 
early employee from ArsDigita, sent me about things they didn't do 
right.  He agreed that I could share it with this list.

While it's true that their situation had some differences, I think the 
commonality far outweighs the differences.

I hope we choose to *actively* learn from his experience.  I think that 
the current discussion falls in the Risk Management category.  What are 
we doing to avoid the pitfalls described below?

--Paul

 From Kai Wu

	Ah, well (grimace) there wasn't a clear plan for transitions -
we built ACS 4 Tcl anew, while ACS 5 Java, of course, shared
little besides the data model with ACS 4 Tcl.  If you started on
a given system (ACS 3, ACS 4, or ACS 5 Java) you usually stayed
on it - translating software plumbing is a nauseating task for
smart programmers, nor is it an appealing expense for clients.
	Zip back to Summer 2000; ArsDigita had a handful of our sharpest
developers coding ACS 4 Tcl (note: we did not have a QA team, or
dedicated doc people). We pre-sold new customers on ACS 4 Tcl for
a while.  We told old customers (on ACS 3 Tcl) we'd take care of
'em - meaning, a developer or two on our end was essentially
stuck in support mode, tied to a legacy client.  At that point we
had a separate engineering team forging ahead with ACS 4 Tcl
pretty much freed of any obligation to do backwards compatibility
with ACS 3; the changes were quite radical.  (We actually tried
to get close to Zope's object model - no easy task using an RDBMS
and a procedural language.)  Of course, the old customers who
managed to survive (the 'net bubble was just starting to deflate
at that point, in mid 2000) were rather curious as to what ACS 4
had.  Some were willing to pay for developer time to do custom
migrations, most not - new features, and not new plumbing, are
almost always brighter lights for aggressive dot.coms to be drawn
to.
	By Fall 2000, with our sales and marketing guys telling us for
the past year that Tcl sucked in the marketplace and that all big
clients were asking for Java, the first ACS 4 release was done.
Almost immediately, we re-focused on ACS 5 Java, while expanding
our engineering team dramatically.  Well this ticked off a lot of
people, internally and externally.  Our professional services
people, having just ramped up on ACS 4 Tcl, were ticked that we
were pretty much abandoning it within a few months.  Clients just
started on ACS 4 Tcl were confused and worried.  We had at end of
2000 almost nothing working in Java, just orders to get it done
ASAP.  As it turned out, 5-6 months later in summer 2001, the
first client projects were tentatively deployed on ACS 5 Java.
Upon reflection I get a little freaked just writing this; in
retrospect it was an insane schedule, driven by no small amounts
of fear and desperation, and as one of the lead managers I walked
a constant tight-rope with client teams who did their best
delivering systems on alpha software.
	Even by the time I left (got axed, urk!) aD in December 2001,
client teams were still ramping up on ACS 5 Java, and product
development was still intense.  And if you visit the Red Hat site
(they bought us out in a rather, uhm, closed-door deal) and look
for CCM, you'll see it continues; I'm quite curious to see it
eventually since I like my former colleagues and liked our
product idea, but I've decided to go with Zope for several of my
own projects.
	Back to the past: Of course, our open-source external community
(see openacs.org) was up in arms about all these changes; first
they were asked to adopt the ACS 3 Tcl orphan.  Then the ACS 4
Tcl newborn came along.  It took them a long time to translate
and begin improving ACS 4 Tcl (they use Postgres, we used
Oracle) - in some ways, that learning curve sucked up such
critical amounts of time and energy that their whole community
suffered; growth in ACS adopters slowed greatly.  I don't have
numbers, but anyone who visited the openacs.org site during 2001
would, with a little investigation, find lots of FUD around
ArsDigita, the ACS, and the community - enough to say, "Screw it,
I'll go with PHP" (small budget) or "Screw it, I'll go with J2EE"
(big budget).  Suffice to say, by the time we said we'll be going
to Java, it was essentially a divorce; a process that is costly
and damaging to both parties, no matter how much either one
denies it.
	Lessons?
	Always have a few good technical scouts providing
well-considered feedback as to long-term product and marketplace
trends so your development efforts have a high ROI and stay
relevant, and so that your product plans are proactive and can be
communicated consistently (perhaps aD started out on the wrong
technical base; perhaps, if we had gone from ACS 3 Tcl to an ACS
Java, and told everyone so for a while, we'd be OK).
	If you have the luxury of time and a slow transition, use it.
	And always, always have something to show people (users,
developers, business people, the press) that works today, is
polished (good installation, ample docs, high quality, and
completed functionality with slick UI), and is clearly being
supported (lists, IRC, forums, newsletters with buzz, and regular
module/Product releases) - that gets you the gold of credibility.
Perhaps today's pace is just a bit slower than the boom time, but
I think even a period of 6 months where you're promising The Next
Great Thing while reluctantly showing your old software with
downcast eyes and shuffling feet will do you serious harm.  And
we all know 6 months is not enough time for anything as big and
cool as Zope 3 to mature.
	Finally, if your product is any good, you will always have your
smartest and fastest developers clamoring to push ahead - let
them, but don't let their buzz stir FUD with the much bigger
group of regular coders, users, clients, etc.  We know those
uber-developers are clever and eager to prove it with some great
software; sometimes too eager.  Disdain for continuity in the
product and disdain for its community can kill or maim the whole
product; a real pity for open-source products, where many people
give very generously of their time and energy.
	There may be more pithy lessons, but that's what I can think of
for now.  Hope this helps,

Kai