Like many people, I’ve been thinking a lot about the live nature of the web more and more recently.
The startup world has gone mad for it. And though I think Microsoft’s Chief Software Architect Ray Ozzie played down the depth of Microsoft’s commitment to it in his recent interview with Steve Gillmor, it’s apparent that it’s at the very least a top-of-mind subject for the people at the highest levels of the biggest companies in the Internet world. As it should be.
The live web started to feel more tangible in shape and clearer for me to see because of Google Wave. Two of the Guardian developers here, Lisa van Gelder and Martyn Inglis, recently shared the results of a DevLab they did on Wave.
My brain has been spinning on the idea ever since.
(A DevLab is an internal research project where an individual or team pull out of the development cycle for a week and study an idea or a technology. There’s a grant associated with the study. They then share their findings with the entire team, and they share the grant with the individual who writes the most insightful peer review of the research.)
Many before me have noted the ambition and tremendous scale of the Wave effort. But I also find it fascinating how Google is approaching the development of the platform as a service.
The tendency when designing a platform is to create the rules and restrictions that prevent worst-case scenario behavior from ruining everything for you and your key partners. You release capability gradually as you understand its impact.
You then have to manage the constant demand from customers to release more and more capability.
Google turned this upside down and enabled a wide breadth of capability with no apologies for the unknowns. Developers won’t complain about lack of functionality. Instead it will probably have the opposite effect and invite the developers to tell Google how to close down the risks so their work won’t get damaged by the lawlessness of the ecosystem.
That’s a very exciting proposition, as if new land has been found where gold might be discovered.
But on the other hand, is it also a bit lazy or even irresponsible to put the task of creating the rules of the world that your service defines on the customers of your service? And do those partners then get a false sense of security because of that, as if they could influence the evolution of the platform in their favor when really it’s all about Google?
Google takes no responsibility for the bad things that may happen in the world they’ve created, yet they have retained full authority on their own for decisions about the service.
They’ve mitigated much of their risk by releasing the code as “open source” and allowing Wave to run in your own hosted environment as you choose. It’s a good PR move, but it may not have the effect they want it to have if they aren’t also sharing the way contributions to the code are managed and sharing in the governance.
They list the principles for the project on the site:
- Wave is an open network: anyone should be able to become a wave provider and interoperate with the public network
- Wave is a distributed network model: traffic is routed peer-to-peer, not through a central server
- Make rapid progress, together: a shared commitment to contribute to the evolution and timely deployment of protocol improvements
- Community contributions are fundamental: everyone is invited to participate in the public development process
- Decisions are made in public: all protocol specification discussions are recorded in a public archive
Those are definitions, not principles. Interestingly, there’s no commitment to opening decision-making itself, only sharing the results of decisions. Contrast that with Apache Foundation projects which have different layers of engagement and specific responsibilities for the different roles in a project. For example,
“a Project Management Committee member is a developer or a committer that was elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, an apache.org mail address, the right to vote for the community-related decisions and the right to propose an active user for committership.”
That model may be too open for Google, but it would help a lot to have a team of self-interested supporters when things go wrong, particularly as there are so many security risks with Wave. If they are still the sole sponsor of the platform when the first damage appears then they will have to take responsibility for the problem. They can only use the “we don’t control the apps, only the platform” excuse for so long before it starts to look like a cop out.
Maybe they should’ve chosen a market they thought would run with it and offer it in preview exclusively for key partners in that market until Google understood how to position it. With a team of launch partners they would have seemed less autocratic and more trustworthy.
Shared ownership of the launch might also have resulted in a better first use-case app than the Wave client they invented for the platform. The Google Wave client may take a long time to catch on, if ever.
As Ray Ozzie noted,
“When you create something that people don’t know what it is, when they can’t describe it exactly, and you have to teach them, it’s hard…all of the systems, as long as I’ve been working in this area, the picture that I’ve always had in my mind is kind of three overlapping circles of technology, social dynamics, and organizational dynamics. And any two of those is relatively straightforward and understandable.”
I might even argue that perhaps Google actually made a very bad decision to offer a client at all. This was likely the result of failing to have a home for OpenSocial when it launched. Plus, it’s never a good idea to launch a platform without a principle customer app that can drive the initial requirements.
In my opinion, open conference-style IM and email or live collaborative editing within docs is just not groundbreaking enough as an end-user offering.
But the live web is fractionally about the client app.
The live web that matters, in my mind, harnesses real-time message interplay via multiple open networks between people and machines.
There’s not one app that runs on top of it. I can imagine there could be millions of client apps.
The Wave idea, whether it’s most potent incarnation is Wave itself or some combination of a Twitter/RabbitMQ mesh or an open XML P2P server or some other new approach to sharing data, is going to blow open the Internet for people once again.
I remember trying very hard to convince people that RSS was going to change the Internet and how publishing works several years ago. But the killer RSS app never happened.
It’s obvious why it feels like RSS didn’t take off. RSS is fabric. Most people won’t get that, nor should they have to.
In hindsight, I think I overvalued RSS but undervalued the importance of the idea…lubricating the path for data to get wherever it is needed.
I suspect Wave will suffer from many of the same issues.
Wave is fabric, too.
When people and things create data on a network that machines can do stuff with, the world gets really interesting. It gets particularly interesting when those machines unlock connections between people.
And while the race is on to come up with the next Twitter-like service, I just hope that the frantic Silicon Valley Internet platform architects don’t forget that it’s about people in the end.
One of the things many technology innovators forget to do is to talk to people. More developers should ask people about their day and watch them work. You may be able to breakthrough by solving real problems that real people have.
That’s a much better place to start than by inventing strategic points of leverage in order to challenge your real and perceived competitors.
Related articles by Zemanta
- Google Wave: Do You Think It Will Succeed? (mashable.com)
- On brand consistency and BHAGs (factoryjoe.com)
- Google Wave and Social Software 2.0 : Finally the raise of horizontal CESA Platforms and vertical CESApps? (stephanecroisier.jahia.com)
