in a secure manner. So we went for a desktop architecture.
Livingston: So this is a big problem that you were approaching. How did you
start?
Ozzie: Before I start a company, I typically write a couple of founding documents.
One of them is very outside-in: it’s a scenario-based document, describing
the high-level challenge that I’m trying to address and the end user
scenarios that we are trying to solve. This attempts to explain what we’re trying
to accomplish to anyone who joins the company or we might need to get financing
from.
Then I create a second, bottom-up document describing the different technologies
that will have to be assembled to accomplish that vision.
The first thing we did in both Iris and Groove was get a big open office and
recruit a core team of people. Generally these were people I’d worked with
before, so I wouldn’t have to get past the trust issue involved in understanding
what they are good at and what they’re not.
And we’d just sit down with the whiteboards and just try to work through
some of the more difficult algorithms, make key tooling decisions. Early on in
Groove, we had a very big decision to make: do we do it in C++ or do we do it
in Java? These types of decisions are important because you can never go back
on them once you’ve started down that path.
In Groove’s case, there was a very risky piece of technology—a certain algorithm
for synchronization that we didn’t even know if we could do. And we didn’t
want to hire more people and really get going until we knew we could
accomplish it. It took about 3 to 4 months before we were confident that we’d
be able to actually build what we wanted to.
Architecturally, Groove was a real contrarian play at the time. This was in
’97, an era where most people were saying, “Things will move from other architectures
to the Web.” We were basically saying, “The Web will hit its limits at
some point for certain applications, and we want to go to a peer-to-peer architecture
that would complement the Web, not replace it.” For a certain class of
applications it would be very effective. It’s a masterless synchronization where
people could do things like work independently on all these different peer
nodes and the algorithms would get everyone in sync.
It can get very complex when you have a dozen people and they’re in different
subnets. Eventually these people come together and it’s complicated to
make sure all the changes get applied in a uniform fashion for everyone. So we
worked through that on the whiteboard and then in a prototype. Once we were

Похожие записи:

• in a secure