From: Rohit Khare (Rohit@KnowNow.com)
Date: Tue Oct 24 2000 - 12:49:18 PDT
Interview with Jack Ozzie
The Care and Feeding of a Platform
Or
"How We Learned To Love The Ecosystem"
Jack, the first release is still being polished, yet you have
committed major resources to developer support. Few startups assign
this task to a co-founder like yourself. Why has Groove Networks
focused so intently on the development community?
[RK: Well, if you're building a platform -- genuinely so -- then
evangelism and listening is the job of every single manager,
including top management]
You're right about our commitment. The key word is "Networks". We
based Groove's architecture on peer-to-peer networking; our culture
also treats developers as peers. We are building a complete ecosystem
that begins with our team but includes developers and end users as
first-class team members. We count on developers to treat our tools
as the jumping-off point for building far cooler tools and
applications. While the Groove platform expresses the model
elegantly, the quality of the tools they build will measure our
success.
[Nice counterspin to the Intel P2PWG debacle, since they put another
$10M into the kitty]
Can you describe this concept of a peer-to-peer platform in more
detail? What makes it a platform rather than an application?
We were excited about peer-to-peer from our beginning three years
ago, long before it became an industry byword. We realized that
person-to-person or point-to-point communication would define the
next stage in network technology. Even something as simple as instant
messaging, let alone email, revealed the dynamic potential for
millions of people to communicate "out of band" while immersed in
other contexts, whether a business process, a game or a family
conversation.
[RK: IM is the true godfather here: major points for seeing it coming
as soon as they did!]
We could have delivered vertical applications for this space but the
set of needed applications exploded on us. What end users wanted were
instant-on, low-maintenance, persistent "spaces" they could share
with others. What we really wanted - remember, we are developers too
- was a killer platform for building those killer apps. These
requirements forced us to solve a host of really knotty problems,
many of which go back several decades, but were brought into sharp
focus in a peer-to-peer design.
[RK: Remember: platform wins like windows are about solving very old
problems, on top of very rickety substructures -- that's what
delivers real value, not abstraction for abstractions' sake]
How do you manage accounts, identity and security; provide
communication transparency so users don't sweat IP numbers; deliver
auto-magical replacement of updated components; synchronize delta
changes at cell- rather than file-levels? Once you've done that (and
more than that), how do you make it possible for developers (and even
end-users) to create or modify tools for that platform with maximal
component reuse while inflicting minimal pain?
[RK: oooh! Cells! nice to see that object metaphor resurfacing. I like]
Of course, we had no ambition to create an operating system. But it
turned out that creating a platform to satisfy the most demanding
developers - ourselves - meant addressing the near-terminal overload
of the Web metaphor across many domains.
[C'mon Jack, nothing like writing an operating system in JavaScript :-]
Remember, we had been involved with a platform - Lotus Domino - that
ultimately supported entire enterprises. We launched an equivalent
effort here. We envisioned and implemented a platform that will
support - eventually - hundreds of millions of users without any
reliance on central servers. Plus, we must assure complete enterprise
confidence in the fidelity and security of every data element cycling
through that wild world. Consider the implications. Tough stuff, but
great fun.
Will Groove be ported to other operating systems? How does it
co-exist with other proposed platforms - for instance, Microsoft's
.NET initiative?
Windows was the obvious first choice for us, but we are already
running Groove under a Wine-enabled Linux. As Apple's OS/X matures,
we'll take a serious look at that. Support for PDA and mobile devices
is already factored into our architecture.
[Nice sop to Apple. It will be a hard haul, since even MS can barely
'port' COM apps over. I'd surmise it'll take a ground-up rewrite, and
it will be damn cool, but that's the cul-de-sac Apple/NeXT have been
living in for soooo long now]
Microsoft's .NET is a huge roadmap, covering a big territory. A lot
of it, understandably, transitions today's desktop clients and
servers to web-centered services. Groove systems integration
solutions which connect to Web-centric processes will greatly benefit
from .NET services, especially through open standards such as SOAP.
On the client side, .NET is about universal run-time, which makes it
easy to design components and applications whose objects interact
across languages. Groove's component-based architecture will play
well with components built in all of the popular languages slated for
use in .NET, including Visual Basic, Java Script, and C#, as well as
traditional languages such as C++. I think their managed code sandbox
is perfect for Groove's positioning as a trusted domain host
application in the .NET world. Groove will fully support .NET.
[Yep -- it's an excellent map onto .NET I can certainly see why BillG
took the time to praise their work. It really could become a
laboratory...]
Your description of the enormous challenges of building a
peer-to-peer platform was almost scary. How hard will it be for
developers to build tools using Groove?
Building good software is never as easy as anyone would like, but our
early development partners are blown away by the speed and leverage
they are getting with the platform framework.
Let's start at the top. Remember that we built the first Groove tools
and the Groove transceiver using the same lower-level components of
the framework that we are offering developers. In fact, not only
developers but end users can customize the looks-and-feels of the UI
with skins and other layouts. If you can build a simple form in HTML,
you're good to go.
[If you can build a simple form in HTML, and wire it up to a
real-time, peer-to-peer XML message passing architecture, why not
deploy it in any 4.x generation Web browser on the planet without
downloading a thing?]
The framework consists mainly of a large set of components at varying
levels of abstraction. Users who are reasonably comfortable with a
scripting language like Java Script, Python or Visual Basic can
specialize existing Groove tools or combine tool components into new
tools. It is only a little more difficult to build tools from scratch
- and that can often be done entirely within a scripting language as
well.
At a somewhat lower level, we have built engines (for instance, to
manipulate record sets) that manipulate the underlying data for the
higher-level tool components. We envision building more high-leverage
engines as our job initially, but developers fluent in COM and
thread-safe languages like C++ are also encouraged to develop engines.
In one way or other, the vast majority of Groove users will "program"
Groove. This, again, is a key part of our vision for peer-to-peer and
for the ecosystem.
Okay, here is where the rubber meets the road: is Groove compliant
with emerging standards or have you struck off in uncharted
directions?
Great question. We are totally lined up with the most popular
emerging standards.
First, while we respect CORBA as well as the Java-based culture, we
chose COM for our component architecture. We view COM as a standard,
not an implementation. While our current applications are
high-fidelity Windows tools, the Groove platform factors COM entirely
for cross-system portability. We were delighted to see that the
recent Mozilla project has independently retraced much the same
ground we have covered with COM.
[Wow! This is a pleasant surprise. Perhaps they do indeed have the
abstraction layer that could allow Mozilla to grow into the same role
as a groove transceiver (and hence, avoid putting portability costs
on Groove's bottom line]
Second, XML is everywhere in Groove. Its centrality cannot be
overstated. As our core data model, we rely on data synchronization
within XML documents throughout the shared-space model and between
shared spaces for account and identity management. We were one of the
earliest adopters of the XML-RPC model as well as, more recently,
SOAP.
[Angle brackets make data more aerodynamic -- HFN :-]
Third, though our platform is entirely geared to application
development, we did not create a proprietary IDE or programming
language. Before we built the transceiver, we used standard C++ and
Visual Basic IDE's to hook up to our own framework. While it wouldn't
surprise us to find developers building custom IDE's for Groove, we
won't be doing that - nor is it necessary.
I notice that you have several times referred to you and the team as
developers yourselves. How has your own experience as developers
shaped the support plans?
Let me give you a specific example. Many of our partners are tasked
with integrating ad hoc conversations cycling "around" the business
process back to the enterprise - starting from the center, working at
the edge and then returning data to the center.
As we developed the platform, we faced these same integration
challenges. Two primary patterns fell out that cover most integration
requirements. We are specializing an integration framework within the
platform as well as developing a Groove Integrator's Guide to help
our fellow developers.
The support plan is really simple and straightforward: we have built
a world-class platform with a real shot at transforming the way the
Internet is used. Refining, extending and scaling that platform will
keep us busy into the foreseeable future - and centered on the part
of the mission that only we can fulfill.
We would rather use our other internal resources to provide top-notch
support to our partners than compete with them. Starting with our
early development partners, we will be rolling out training and
certification programs (already underway). Developer conferences will
follow as appropriate.
Finally, please don't forget the broad reach of Groove's development
ecosystem. There are sixteen-year old kids out there that will start
by customizing skins and end up dazzling us with full-blown Groove
tools. We can't wait to see them. After all, we're not only Groove
developers but Groove users too.
[Dammit, where's our own Children's Crusade? I'll see your 16 year
olds and raise you an eighth-grader! :-]
---
<quote>an aerodynamic .sig</quote>
-- <author>creator</author>
This archive was generated by hypermail 2b29 : Tue Oct 24 2000 - 17:50:23 PDT