From: Adam Rifkin (adam@KnowNow.com)
Date: Thu Dec 28 2000 - 20:10:10 PST
This looks like the kind of piece most other magazines were publishing
in late October. How did the Red Herring fall two months behind?
http://www.redherring.com/vc/2000/1228/vc-mag-89-ozzie122800.html
> A cult hero in the software world
> By Bridget Eklund
> Redherring.com, December 28, 2000
>
> This article is from the January 2, 2001, issue of Red Herring magazine.
>
> Ray Ozzie wants to unlock once again the technology chains that bind
> you. After three years of monastic silence, the software cult hero who
> brought Lotus Notes to its 60 million users worldwide has pulled the
> wraps off his latest creation: peer-to-peer collaboration
> software. Mr. Ozzie, 44, and his band of merry conspirators at Groove
> Networks are betting that Groove, as the software is called, will become
> as ubiquitous as email or the Web browser.
>
> The soft-spoken, down-to-earth developer, whom Bill Gates calls "one of
> the best programmers in the universe," got his first understanding of
> the power of connecting people in 1979 as an undergraduate at the
> University of Illinois at Urbana-Champaign, where he worked on the
> seminal Plato project. During the following decade, when the PC was
> considered a device that could empower the individual, Mr. Ozzie was out
> there heralding it as a means to empower collaboration. And he has never
> strayed from that vision. While at Lotus, Mr. Ozzie was instrumental in
> the development of Lotus Symphony and Software Arts's TKSolver and
> VisiCalc, but he wanted to be more creative. So in 1984, he set up an
> offshoot company, Iris, and built what would become Lotus Notes, the
> software that forever changed the computing landscape. Those in the know
> say that Notes actually saved Lotus Development. The reason: Microsoft
> (Nasdaq: MSFT)'s Excel surpassed the Lotus 1-2-3 powerhouse and became
> the motive for IBM (NYSE: IBM)'s buyout of Lotus in 1995.
>
> Today, Mr. Ozzie is leveraging the same principle underlying the famed
> Lotus Notes to launch his new software project, Groove. It's essentially
> a P2P platform that will allow close, secure, and spontaneous
> collaboration among small groups. But any comparison of Groove to
> Napster -- the music file-sharing program that took the P2P concept
> mainstream -- is somewhat misleading. Although the distinction can be
> fuzzy, Groove is less P2P and more an embodiment of groupware. Groupware
> packages like Notes comprise a set of tools that bring people together
> for a shared purpose, whether it's just to hang out and play chess or to
> formulate the details of a team business plan.
>
> Groove's official coming-out party took place in New York in October
> before an audience of Ray Ozzie rubberneckers, whose interest was
> clearly piqued by years of his self-imposed silence. But Mr. Ozzie
> flatly denies a gambit to generate buzz. "It's very difficult to build
> something interesting and new in a fishbowl," he says, by way of
> explanation. Only a small number of Groove's 150 employees got the full
> scoop on the company's plans. And being bunkered in a refurbished shoe
> factory in the former mill town of Beverly, Massachusetts, didn't
> prevent Groove from luring talent.
>
> KILLER GROOVE
>
> Mr. Ozzie's goal from the beginning was to keep it simple -- his model
> was the Palm (Nasdaq: PALM) Pilot. Users access the program through a
> browser-like interface called a transceiver. They can create a workspace
> simply by extending an emailed invitation asking anyone, anywhere to
> join in. Those who don't have Groove can download it for free (the
> software is currently available only for Windows, with Linux and
> possibly Mac OS X to follow.) It's all bait to spread the platform.
>
> Once gathered, the group can work on a project, incorporating a
> collection of online tools to facilitate interaction: a note or sketch
> pad, file-sharing capabilities, a Web browser, a calendar, and an
> address book, among others. Everything is protected by powerful
> encryption. Changes made by any one person are automatically updated on
> every PC in the shared space. And if someone drops out, they can
> reconnect at any time and find that they're still perfectly in sync with
> the rest of the group.
>
> But what truly differentiates Groove from most other Internet programs
> is that it's expandable. Groove users can dream up all kinds of
> applications, which can be integrated into the platform and passed along
> to others. All they'll need are programming skills to match their imagination.
>
> But as with any group project, designating leaders in a virtual space
> can cause some headaches. "You have to have roles already established --
> who's taking notes, who's working on the document," says Kevin Morgan,
> director for the Hurwitz Group, a research firm. "It's just not as
> instantaneous as you would hope it could be." And there are other
> hitches, too. Critics who've test-driven Groove complain about slow
> downloads and delays in transmitting messages, and they still have some
> concerns about security outside the firewall.
>
> To date, Groove has raised $60 million from Accel Partners, Intel
> Capital, and private investors. The company will sell some versions of
> its software and license its technology to developers. It's likely to be
> years before Mr. Ozzie's company can turn a profit. Success ultimately
> depends on whether the software, like Lotus Notes, becomes a habit
> adopted by millions of customers. And if it doesn't? "Well, I will have
> tried," says Mr. Ozzie. Spoken like a true entrepreneur.
---- Adam@KnowNow.ComRay Ozzie: This is the inverse of a Web-services play. With Groove, the app lives on all the clients and the network is used as a pipe between the clients. This is not a browser-based app. We use browser technologies a lot, but the browser has a paradigm that's very locked in right now. The browser is somewhere you go to look at information and do some simple form-based interaction with Web sites -- but the paradigm is principally one of pulling information from Web sites.
An e-mail paradigm is very two-way; you've got this one-to-one relationship between you and the people whom you're dealing with.
...
Ozzie: The simplest is a page of XML where you describe what components are in a tool. For example, in the sketch tool, there's a component for each of the elements -- the sketch, the text, the buttons. You declare where the components come from, then write a little JavaScript to weave the events coming from one component sending into another. One script says "When I press this button, tell this component to instantiate a new sketch and these little navigators between them."
To the extent that you can build an app out of the rich set of components that we provide, you don't have to write anything beyond that JavaScript and that little XML page.
...
Ozzie: The component manager uses standard ftp or http as the file-transfer mechanism -- and we integrate with our own Web services via SOAP. Developers build these tools. They package them up in the Web site for downloading, and then they just get dynamically assembled.
...
Gillmor: Using WebDAV?
Ozzie: No, remember, this is peer-to-peer-to-peer. Everything is happening in parallel in this architecture amongst all the clients. There's no central server.
...
Ozzie: It's like a router with a disk. It's literally like an SMTP relay. Updates move through it, and the high-water mark of how much storage you're using depends on how long the recipient has been off-line. When you download the product, every user will get a default quota in megabyte minutes or days or whatever, so that they can get a taste for what [the enhanced performance] is like. And we'll offer a higher quality of service -- if you really want to buy a gigabyte worth of buffering, we can offer that to you. But if you're using Groove in mostly an ephemeral fashion, you won't need the service. If you use Groove a lot with people on the other side of the globe, you probably will need it a lot more.
In a low-speed dial-up situation, we can use the relay service as a proxy. It auto-detects the bandwidth so that one copy of your information goes out and gets forked out when the bandwidth improves. Another function is firewalls and Network Address Translation (NAT) boxes. If A and B are in different organizations and you can't set up a direct peer connection between the two, the relay service can act as a proxy. The proxy holds the messages for B who then pulls the data in through the firewall.
We wanted to have browser-like simplicity in terms of using the product -- no configuration of ports or your IP address, or what your ULS server is -- we just wanted it to work. And we wanted it to adapt to the topology that you have, so if you happen to be behind a corporate firewall or a NAT, it just works. If I happen to have a dial-up connection, it just adapts. We don't have to have a PKI, you don't have to get a VeriSign certificate -- the encryption is more of a peer security model. We wanted to give this illusion of transparency -- peer transparency across the whole Internet, no matter what the topology happens to be.
...
Gillmor: Do you think that anyone would find it useful to run Groove applications as a component within a browser?
Ozzie: I tend to think not. I tend to think people would rather have a client that gives them navigational capabilities -- once they get comfortable with it -- that are more tuned to that task. But flip this on its head -- I really do think ubiquitous access to information is an issue. There may, indeed, be people with whom you want to interact in this support app that don't have Groove -- who are using it at a kiosk or something, and don't want to get those bits onto their computer for some reason. For that environment, there's a completely separate sub-system -- a "KnowBot" sub-system.
...
Gillmor: Why did you choose JavaScript?
Ozzie: When we build apps, we have to choose a language -- we didn't want to build one. We could have used anything -- C++, VB, JavaScript, VBScript, Java. We use JavaScript because it's easy to hire Web programmers who have done JavaScript. They're probably the most available, and ECMAScript is portable to the other players.
Gillmor: What's the XML value proposition? You've said it a lot . . .
Ozzie: . . . about a hundred times. This is a product that's born on the Net and born with XML. Let's start with the app-development side. The paradigm of the product is like the Web -- you go there to do things, go somewhere else, and go somewhere else. We must have a persistent store so that you can store tons of data -- and we just maintain it. What you're viewing when you go into the app is a small bit of that data. We don't want to go in, open a ton of files, and read them in. We need a database underneath it.
App-development-paradigm people are getting very comfortable with dealing with XML at a programmatic level. If people are going to become more and more familiar with data representations in XML, then we should build an object store that, at its birth, is very adept at persistent handling of XML. So, we built this storage system that has APIs that are XML semantics. Underneath it are various service providers, one of which lives on XML files in the file system, one of which is an XML-object store, one of which is a ZIP-file store, and one that is multi-part MIME.
The persistent tools sit on top of the object store get better performance and robustness, so that if you have to "control-alt-del" you don't lose anything. Remember, we don't build on a document paradigm. Every tool has its own data model. We want to make sure we are building on an environment rich enough to define new schemas and data models, and still store it in an object store.
On the communication side, we need to get little pieces of information from one machine to another. It's much more convenient to package commands in XML in the controller layer and route it over the wire [than use something like CORBA]. You don't have to worry about layers and layers of software to pack and unpack. It's a little bit fat, so we compress it with WBXML to remove the redundant text information, and then encrypt it. It's a great, flexible description environment when we don't know in advance what the platform is going to be used for. And because we have all these XML services available, it's the representation format of choice throughout the app -- for everything we do.
-- a much better article on Groove at http://www.xmlmag.com/upload/free/features/xml/2000/05win00/ro0005/ro0005.asp
This archive was generated by hypermail 2b29 : Thu Dec 28 2000 - 20:15:27 PST