[A picture of private offices at Fog Creek Software] Alert! This ancient trifle retrieved from the Joel on Software archive is well-past its expiration date. Proceed with care.

Joel on Software

Are the Groove Designers Architecture Astronauts?

by Joel Spolsky
Sunday, April 22, 2001

George Moromisato at Groove Networks writes:

I read "Joel on Software" more or less religiously and I'm always intrigued by your insights. Your column on Architecture Astronauts was no different, except for your dismissal of Groove as software that "miss[ed] the point" of Napster's example. I hope to take a few moments of your time to convince you to give Groove another chance.

Like Napster, we also consider peer-to-peer to be a means to an end, not the end in itself. For Groove, the end goal is not to search for music on the Internet (as cool as that is); Groove's end goal is to allow people to interact and share information on the Internet without regards to time, distance, or corporate infrastructure.

The last point is worth diving on: Today, if I want to share information with someone outside my corporate infrastructure I have three plausible choices: 1) use email, which is not very interactive, has very little persistence, and is often insecure; 2) use an internal web server, which requires me to ask my IT administrator to either open up a hole in the firewall or to deploy some section on our extranet; or 3) use a public web server, which now is privy to my corporate data and may take it with them when they go under. The cool thing about Groove, and one of the problems that we were trying to solve, is that I can use it like email to communicate with someone outside my infrastructure (they can download the client for free) and I don't have to worry about a server (we are peer-to-peer when appropriate) or a firewall (we go through firewalls) or security (since Groove communications are by invitation only and heavily encrypted). The best part, IMHO, is that, while we provide some basic tools to interact inside a Groove space (sharing files, doodling, voice chat, forums, etc.), we have also built a platform that allows third parties to extend Groove in whatever direction they want, all without having to ask us to change our servers or upgrade the core product!

[pause while I stop hyperventilating]

The bottom line is that I think it was unfair of you to consider us Architecture Astronauts. It is true that we do not solve the problem that Napster was trying to solve, but I think we have been successful at solving the problem that we set out to solve. Also, to be fair, we have managed to ship a product (and even sell it to people) unlike some of the Architecture Astronauts that you are thinking of.

Anyway, I hope I haven't completely wasted your time. Thanks for your columns and good luck with everything.

George Moromisato
Chief Product Designer
Groove Networks

My reply:

I like Groove, I think it's a nice architecture. I think in many ways it's Notes done right, eliminating one of the biggest problems with Notes -- the server bottleneck which crippled large Notes installations.

On the other hand, Notes was the most misunderstood product in history :) It was being sold as a groupware platform, but in reality, it was being bought (and used) as an email program. A few people used the discussion groups and document databases, and an even smaller number actually created applications on top of Notes, but the reason companies with 50,000 people bought Notes was really for email.

Which, unfortunately, didn't work quite well enough in Notes. At Bankers Trust in the mid-90's, management ruled that no new Notes accounts could be created, because of an incident where Notes replication between servers managed to tie up the company's crucial transatlantic link thus cutting London off from New York for an entire trading day. As a result Bankers Trust was in the awkward position of ruling "no new Notes accounts!"

At Viacom a couple of years later, Notes was shelfware because the email component was too hard for most people to figure out. Everybody in the company had AOL accounts which they expensed because they could figure that out.

Note that none of this is necessarily a bad thing from a company perspective: Notes sold scrillions of copies and was considered a raging success. In theory, Groove is even cooler, because it's Notes without the server headaches.

Anyway, now we're talking about architecture. Let's talk about features. The applets you ship with are all spiffy but not ultra-compelling, because you can often get the same functionality elsewhere. And it's the applets that are going to sell Groove, not the architecture. If you don't believe me look at NeXT and Be ... you can build the best dang computer in the world with a killer architecture, but if it doesn't run Microsoft Excel, nobody wants one. When you say "it's a platform, third parties will build things," you have to explain what KIND of things and why THEY will be killer apps that sell the architecture. If you keep hearing the same examples, you're in deep trouble -- like the idiot WAP people who talk endlessly about how "you'll walk by a starbucks and the GPS in your phone will coordinate to beam you a coupon for that starbucks." I've heard this same example a zillion times from "location based wireless" architecture astronauts and it amuses me, because it solves the one problem that coffee shops DON'T have, namely, advertising to people who are standing right in front of the store! :)

So... yes, you shipped a product, and sold it to people, it's great, I believe you. But if you want it to be The Next Great Thing it has to be more than architecture, it has to enable things that people really need.


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, easy web-based collaboration software, FogBugz, an enlightened bug tracking and software development tool, and Kiln, a distributed source control system that will blow your socks off. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky