Just about every blog I’ve checked this morning had a link to Ozzie’s reply to Joel’s article on Platforms. The fact that a lot of people expected a public reply from Groove/Ozzie tells a lot about how blogs have changed high-tech PR game. Can’t wait for other software executives to catch up!
In my opinion Ray Ozzie did a wonderful job explaining Groove’s strategy. The bit I especially like is the appearance of previously unpublished info on Groove OEM Kit. The existence of such kit confirms that Groove does recognizes the demand for Groove runtime and is working towards making it generally available. This is good news.
But notice have Ozzie skillfully blends two things together. He calls Groove Workspace an application, but it is a platform too. Yet, there’s “Groove Platform OEM Edition” as well, but its not yet generally available.
Let’s see if I can get it straight. First of all, there’s Groove Platform. 3rd parties can develop applications on it using OEM Kit. Then, there’s Groove Workspace. It is an application that runs on top of Groove Platform, but also allows 3rd parties to extend it by writing Groove Workspace Tools.
The best analogy I can find is Windows and Office. Windows is a platform. Office is a Windows application, but you can also extend it by writing Office plug-ins and marcos.
Ok, this sounds very very reasonable and healthy. So what’s wrong with Groove’s picture? The priority. Clearly, Groove has made a conscious decision to invest much more in support for developers of Groove Workspace Tools while providing a bare minimum support for Groove Platform developers. Imagine if 95% of MSDN was allocated for information on how to develop Office plug-ins and 5% was given to help out Windows application developers. And you had to "negotiate" with Microsoft to get that 5%!
From the architectural perspective, there’s a risk that some of the critical functionality would creep into Groove Workspace from Groove Platform. Don’t get me wrong, I’m convinced that Groove’s architects are very smart and experienced people, but its really tough to build a nice generic platform when you have one single application that tests it.
I think Groove has made a strategic mistake, but its not too late to correct it. Groove needs to increase the priority of getting Groove OEM Kit into general availability. They also need to start encouraging people to develop on Groove Platform just like they encourage to develop on top of Groove Workspace. So far Groove have done a really good job listening to developers, so if enough people complain, I believe they will find the way to solve the problem.
In my opinion Ray Ozzie did a wonderful job explaining Groove’s strategy. The bit I especially like is the appearance of previously unpublished info on Groove OEM Kit. The existence of such kit confirms that Groove does recognizes the demand for Groove runtime and is working towards making it generally available. This is good news.
But notice have Ozzie skillfully blends two things together. He calls Groove Workspace an application, but it is a platform too. Yet, there’s “Groove Platform OEM Edition” as well, but its not yet generally available.
Let’s see if I can get it straight. First of all, there’s Groove Platform. 3rd parties can develop applications on it using OEM Kit. Then, there’s Groove Workspace. It is an application that runs on top of Groove Platform, but also allows 3rd parties to extend it by writing Groove Workspace Tools.
The best analogy I can find is Windows and Office. Windows is a platform. Office is a Windows application, but you can also extend it by writing Office plug-ins and marcos.
Ok, this sounds very very reasonable and healthy. So what’s wrong with Groove’s picture? The priority. Clearly, Groove has made a conscious decision to invest much more in support for developers of Groove Workspace Tools while providing a bare minimum support for Groove Platform developers. Imagine if 95% of MSDN was allocated for information on how to develop Office plug-ins and 5% was given to help out Windows application developers. And you had to "negotiate" with Microsoft to get that 5%!
From the architectural perspective, there’s a risk that some of the critical functionality would creep into Groove Workspace from Groove Platform. Don’t get me wrong, I’m convinced that Groove’s architects are very smart and experienced people, but its really tough to build a nice generic platform when you have one single application that tests it.
I think Groove has made a strategic mistake, but its not too late to correct it. Groove needs to increase the priority of getting Groove OEM Kit into general availability. They also need to start encouraging people to develop on Groove Platform just like they encourage to develop on top of Groove Workspace. So far Groove have done a really good job listening to developers, so if enough people complain, I believe they will find the way to solve the problem.
posted by alexis at 8:07 AM
<< Home