Head of Microsoft Research Rick Rashid talks about ongoing MSR projects.

"Sideshow" is the internal name for a project in which the company has developed an application that displays a series of windows with useful information on a user's desktop. Using XML and Microsoft's .Net Web services technology, Sideshow can reach out to the Web, corporate servers, or the computer's hard drive and provide quick views of data relevant to the user.

Sideshow team has published the project paper last month that described "notification and awareness platform". It looks like intelligent dashboard that apparently is being regularly used internally at Microsoft by 7000 users. Integrated in Office, this kind of tool will represent dramatic evolution of personal dashboard. I predict Office people are or will be working on productizing this. Groove team should definetely take note.

Cathleen Moore reports from IM Planet Conference. These seems to be a consensus amongst the players (Microsoft. Lotus, Groove) on the protocol.

In the end, rather than a feature/function bake-off among vendors, the real value differentiating corporate IM will be the ease with which enterprises can extend IM and presence awareness into applications and infrastructure, [Lotus'] Dies said.

Wanted: software designers who don't know software.

Thoughts on how to build future software.

Execution is king. After reading this interview with Larry Bossidy (ex Chairmain/CEO of Honeywell) I feel a bit uncomfortable spending more than a few minutes writing those strategy notes. His book may not be getting stellar reviews, but the interview is very refreshing.

Steve Gillmor and Mark Jones are interviewing Charles Fitzgerald .NET Strategy guy.

"We're certainly interested in the next generation of tools for access and collaboration and giving people tools to actually do something with that information. And today's portal model certainly falls far short of where we need to be. ... There's a broader road map where I think over the long term you're going to see a hybrid model of [collaboration] services, and we're big, big fans of peer services obviously."

 

Longhorn vs. Groove Platform, Next Office vs. Groove Desktop
The race is on.

Ever since I've learned about Groove I was amazed as to why such obviously useful technology has so little competition. I've explained it to myself as "Well, Ray and his team kick ass". Then, I've learned about that $51M deal and I though to myself - "Wow, Ray and his team really do kick ass! Not only they have great tech, but also Microsoft won't be killing them anytime soon. Perfect!"

Recent news about Windows group buying small P2P company didn't change my views of Groove's team of course, but comes as a sharp reminder of age-old truth about Microsoft - one should treat Microsoft's product groups as successful and highly competitive companies on their own. In order to succeed these "companies" sometimes step on each other's toes. They are opportunistic and may make business decisions that benefit their own group, but at the same time putting pressure on other groups. This rule is espetially true with cach-cows like Windows and Office.

What does this have to do with Groove? I'm guessing Office group (Jeff Raikes & Co.) was the primary proponent of Groove/Microsoft deal. They have good reasons to do so. As Office people were building their road-map, they desperately needed the technology that allowed cross-enterprise online/offline collaboration technology. I suspect they have talked to Windows group and inquired how Windows would address this requirement. At that time Windows people didn't have a good answer. By making the decision to invest in Groove, Office group got their roadmap in good shape. But it also have indirectly put the pressure on Windows group to come out with their answer as to how Windows itself would support the collaboration scenarios required by Office.

The acquisition of XDegrees by Windows' storage group illustrates that Windows group is now serious about providing cross-enterprise file sharing abilities. One can expect Longhorn to provide a lot of Groove-like technology. (One can also expect that Windows implementation will be built on GXA from the ground-up.)

What this all means for Groove? It will soon have competition - Windows. That's... serious competition. (Strictly speaking, Groove's basic productivity tools like calendar, project management kind-of competes with Office, but Groove's integration with Office will likely render those tools irrelevant for Office users).  The good news is Longhorn is far away, so Groove still has time to mature its platform and get good client base. 

The other good news is, Windows isn't after everything that Groove stands for. Groove has three crown jewels in its crown: Moving data cross-enterprise. Working online/offline transparently. Lastly, enabling collaboration features deep inside desktop applications. Windows Inc. wants the first two. The last one is still undisputed and has to be protected at all costs. So in order to sustain the business over the long term, Groove has to excel in enabling collaboration of desktop applications well beyond file sharing, well beyound Groove Desktop. This is Groove's chance to keep being one step ahead of its competitors.

Following-up yesturday's post :- As CNet's Stephanie Olsen reports, big banks begin to pressure IM companies to interoperate. The fact that customers take matters into their own hands shows how software companies have really screwed up with IM. It seems that this time around software companies have a real incentive - paying customers wanting the solution. The common standard will be good news for Groove.

The question is, how much AOL, Microsoft and Yahoo will be charging to let others IM with people on their networks.

 

Weblogs gave you the power of publishing.

Now Jay Link gives you O'Reily cover to go with it!

Make your own!

Thanks go to vowe.net

Lee Finck is ready to give up on IM. He has all the right to. To me and to many other people passionate about software, it is painful to see the lack of technological progress in IM space. It is painful to see so many souls locked up in Socialist Republic of AOL behind the Iron Curtain of proprietary protocols.

That said, I don't believe that the absence of open protocol is the primary reason why there's no IM-based killer app yet, apart plain-text IM itself. Declaring that IM is in dead-end because of absence of interoperability is like saying that software is in dead-end because we have several OS on the market!

First off, the protocol issue is not unsurmountable. Look no further than Trillian for proof. If Trillian managed to unify access to all popular IM platforms, why others can't? Secondly, if someone has a great idea on how to use IM to solve a real problem, why wait for everyone to be on the same network? Why not target one single IM platform? MSN Messenger is open enough. Yes, IM interoperability will help successful application more successful. But it will not turn mediocre software into a overnight hit. Groove is of course a good example of a successful application that will greatly benefit from unified IM. But inversely, if Groove fails, no one can blame the falure on the fact that IM world isn't unified.

It is not how AOL doesn't give a damn I'm frustrated about. It is near complete absence of commercial applications that innovate around IM to solve real problems that I'm puzzled about. Maybe I'm just too impatient...

Another addition to .NET developer's toolbox: Peter Drayton has a very useful little utility  that allows provides automatic call tracing. Extremely easy to use and very practical for debussing those triky remoting or multithreaded pieces.

The TraceHook.NET service is a context attribute that provides automatic call tracing on attributed classes. It traces instance method calls & field/property accesses to the debug output, allowing one to monitor an application as it runs. The trace includes type names, method names, parameter names & values (both [in] & [out]), as well as any return codes or thrown exceptions. Full, commented source is included, thus it should also serve as an interesting demonstration of the use of context attributes & interception in the .NET platform.

The source code was based on beta release of .NET, so I've sent Peter a few code changes to make the tool work with the latest framework.

This will be my next camera. That's when i'll quit developing film and focus on developing software!

Blog bombing

In a bizarre surreal bow to the power of perception on the web, what you say about a page becomes just as important as the actual content of the page. [Uber]

Uber have introduced the term "google bombing". What i'm talking about here is really is a particular instance of unintentional google bombing. Any informaiton in public domain is a double-edge sword.

[TODO - to complete]

Megnut's mom, who once was guest host on Meg's blog, has invented a new idea -- googlecooking. Meg says "My mother types whatever ingredients she has on hand into Google and then picks the most appealing recipe returned in the results." Smart! [Scripting News]

What a wonderful idea! So to define googlecooking in general terms, it is the process of searching the algorithms/resources needed to achieve all possible results using a set of ingridients and pre-conditions.

This might be far fetched, but I wonder how can this idea be applicable for things like supply chain management.  Might be an opportunity for google-based applications for various verticals.

Privacy vs. weblogs.

As people are creating webs of links between weblogs and establish common-interest communities, what are the consequences for privacy?

Preserving privacy means preserving the ability to own and control all of the personal information. It also means the ability to clearly understand what kind of personal information is being produced. From the first look at the issue, it would appear that we disclose exactly what we decide to post to weblog and not more. But as people begin to be part of weblog communities, another kind of personal information is being released. It becomes possible to determine the circle of friends for instance. It becomes possible to track patters behind individual's interests over time; to determine the level of interest of others to a given individual; to tell who's reading.

There's key difference between weblogs and newsgroups where most of the above bits of personal information was already in the public domain.  With weblogs you can reliably answer the question Show me your friends and I'll tell you who you are. Also, with weblogs it is much easier to build analysis tools.

Let's imagine for a second that some guy Joe is an recovering alcoholic. Joe is not talking about this particular problem of his on the weblog. He want to keep this fact private. Now, Joe has friends whom he met in rehabilitation clinic. They choose to disclose the fact that they are recovering alcoholics. Once it a while Joe's friends link to Joe's weblog. Now imagine a tool that tracks links between weblogs over time and achieves statistically representative data sample. When it becomes clear that 10 of his friends have problems with alcohol, will Joe be able to keep his secret for long??? What if Joe decides to run for president?

I'm not trying to be comprehensive here and I'm sure anyone can cook-up another technology-assisted privacy invasive scheme. My point is, many people are not realizing what kind of personal information is really being released as we continue to build these webs of weblogs. Maybe its too early to ring a bell, but weblog tool vendors should definitely think about this (or talk to experts). It is very important to realize they are developing tools that create wealth of personal information and it should be their responsibility to allow users to own and control all of the personal information.

Thanks to Jeroen Bekkers for encouraging me to switch to radio. The tool is very flexible. Switching could be made simpler though - couple of hours if you don't find the homepage template you like. I'll keep blogger-radio bridge running for a while.

My first feature requests:

• Allow automatic import of the content from a different blog and post it with the right dates (in the past).
  
• Pure Windows client for posting that would use MS Word for text entry (a-la Outlook)

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.

It's about time Groove has got some competition!

Matthew French reports on CADwire.net on Availl

From the first glance, it looks like Availl has solved pretty much the same problems that Groove runtime solves (security, firewall traversal, online/offline handling). In contrast with Groove Availl seems to be only focusing on selling the 'briefcase' solution - file sharing and synchronization. Compared to Groove, Availl's file sharing product looks extremely simple to setup and way more transparent - no shared spaces, no UI.

Joel Spolsky has some harsh criticism for Groove strategy. While I disagree with most points expressed in the article, I think the core message is consistent with the one expressed by me here and Philip King on Groove developer's forums. If this sounds odd, read on.

When talking about multi-layer product such as Groove, one should define the terms to avoid confusion. So first, a quick terminology intro. "Groove Runtime" defines a UI-less piece of code that offers such services like secure communication, firewall traversal, persistence model that allows efficient broadcast of data set changes, handling of online/offline contexts, etc. "Groove Transceiver" is an application that uses Groove Runtime to offer the UI for such features as shared space management, user management, instant messaging etc. "Groove Tools" are hosted inside the Transceiver and allow the user to perform a specific function inside Groove Transceiver.

Joel claims that Groove Inc. is making it hard to build applications (Tools) on Groove. I think this statement simply cannot be further from the truth. Clearly, Joel have never tried to create a Groove Tool with VS.NET Toolkit. For a young startup it is truly impressive to see how much effort was put to simply the creation of Groove tools.

Joel also claims that Groove Inc. doesn't know that Groove is a platform. I wonder why is there a developer's zone on Groove's site? Again, this argument doesn't stand basic analysis.

So do I think Joel's article is wrong? No, it simply fails to capture the real issue with Groove - there are two different views of "Groove Platform". One is being offered by Groove Inc. and another is wanted by ISVs.

Groove Inc. defines the platform as Runtime plus Transceiver. Want to build on the Groove Platform - write a Groove Tool. Most ISVs define the platform as Runtime. Period. Most of the people thinking of integrating Groove's collaboration capabilities only want the Runtime. This is why Joel's analysis of cost/benefit of integrating Groove with CityDesk is right on the money - it illustrates the Groove/ISV gap.

In Groove's defense, they do claim that the Runtime can in fact be used by ISVs in their applications (whoever there seem to be technical issues with this model in the current release). But still, the primary positioning of the platform is Runtime+Tranciever.

So, its not that Groove thinks they don't have a platform (or they're clueless) - its just that their priorities are out of sync with those of their partners. This strategy flaw can be corrected. And if enough people complain, I believe it will.

Having a discussion with Mark Smith from Virtual Methods started by comments about what kind of groove tools will succeed.

Mark: Obviously I 100% disagree with your comments about whether Groove Tool Vendors will succeed. The major problems I've got (apart from price/quality issues) with our larger competitors is that they treat software development as almost a solo activity, carried out in an environment tighlty bound to a developer IDE. Your link to the Infoworld Booch interview shows that other firms are pushing in the Analyst<->Designer<->Developer direction, as borne out by their most recent product releases. My view is that the other direction-Customer<->Analyst<->Project Manager -is being neglected. I also know from direct personal experience that a Groove space provides a better way of specifying and designing software than the current hotch-potch of email, Word documents, scribbled notes, meeting minutes and so forth. Would you agree that the integration of requirements, design and project management can only make softeare projects less painful?

It seems we’re talking about two different issues – first being whether Groove tool vendors will succeed and the second being the vision and the target market of UMLTool. Obviously, its not my place to critique UMLTool and Mark's vision behind it. I sincerely wish Virtual Methods luck making it a hit! I’ve only used UMLTool as an example of a new application that knows collaboration in an established market of feature-rich tools that don’t know collaboration. Fair?
I think we’re in agreement that current software development tools simply lack collaboration feature set. Yes, software development is highly collaborative process that involves many different types of stakeholders as Mark points out. I would pay to have the better collaboration tools for software developers. But I would only pay if those tools don’t take away my other favorite features. In my work I use UML using Visio. I’ve selected this tool because it is feature rich, integrates with office, stable, gets the job done, blah blah blah. But this tool doesn’t know collaboration. So naturally, I turn to UMLTool. Will I end of switching from Visio to UMLTool? I will, only if UMLTool doesn’t take away all of my other favorite features present in Visio.
I believe this very logic will be used by majority of buyers of Groove Tools. If users find groove tools sub-standard in areas other than collaboration, I believe they will opt to use their current tools and simply end up using Groove for file sharing. Same logic will apply to Groove-created tools like calendar. What would Outlook user prefer while arranging a meeting with a partner: seeing their shared calendar directly in Outlook or switching to different UI of Groove, going in the shared calendar and trying to figure out the conflicts with his/hers personal Outlook calendar?
Would you agree that sub-standard tools that know collaboration are less valuable to the user than full-featured tools with added collaboration features?

While looking for info in groove integration exampes I stumbled on this post:

Date Posted: May/10/2002 11:02 AM

Posted By: philking (Member)

Moderator,

Also checked the controller and noted that is shutdown fine there. The sample controller code is too simplistic to use as any sort of meaningful test. Note that opening tools as per the sample doesn't allow the tools to work at all!

If GN is serious about selling Groove for controller use then that comittment should be evident through the samples and adequate beta testing in the contoller environment. This would also be an excellent test for the API classes which like any good class structure need to work independently of any UI or Tranceiver specifics.

Controller apps could end up representing a huge slice of the total user base of Groove technology. Currently the transceiver and standard UI components are far too limiting for powerful app developent. This shows through all tools currently available and the time, effort and cost to produce such mediocre functionality. The end result is that users come away less than impressed with Groove. Indeed many are reluctant to use it because the interface and functionality is far inferior to which users are accustomed in most windows apps these days. To understand why, one can simply look at the ListView component. It's functionality is so crude it wouldn't register on a feature comparison chart up against mature ActiveX grid controls on the market today. Sure we can sort of wrap ActiveX in tools but that does NOT deliver the performance or functionality of a component designed to be hosted in an ActiveX container totally integrated into COM.

Personally I believe developing Groove apps in a mature environement supporting native ActiveX containment is the way to go. Rich and diverse functionality can be delivered at RAD speeds providing the API doesn't choke developers efforts along the way.

GN marketers need to remember that no matter what hosts Groove technology, the Tranceiver or a Controller, a Groove license sale is a SALE! Controllers need more attention. Please bring this crucial issue up with GN management and help Groove proliferate to every desktop.

Still with grand hopes for Groove ...
Phil


05/10/2002 11:18:34

This post resonates with my concerns about groove's busines model. As much as I'm excited about groove's technology, collaboration should remain a feature of a desktop application. Collaboration framework/platrofm like groove must avoid making ISVs re-write their existing applications just to enable collaborative workflows. Even less groove should try to re-write those apps themselves!

I'm sure we all want to see superb collaboration functionality in something like Adobe Photoshop to take one example. Does groove seriously beleive that adobe will re-write their system to be hosted inside groove's UI?

What's more worrisome is the fact that some of groove partners seem to buy this strategy. They seem to beleive that groove is their golden opportunity to leapfrog established competition.
Let me pick on Virtual Methods UML Tool. Forget collaboration for a second. How does the UML modeling funtionality of this editor compares with competition (Visio, Rational Rose)? I think UMLTool is doomed because of very strong compatition it faces.

The bottom line: Fantastic technology like groove will not cause people to abandon their favorite tools. Groove should pay more attention to integration into existing applications.

Just read Understanding GXA by Don Box. Very nice brief (8 pages) overview of a gigantic undertaking of building infrastructure protocols for web services. For people interested in WS protocol, i definetely recomment reading this article before diving in detail of any specific any specific protocol.

"Spend A Day with .NET" Coding Contest
What a wonderful idea by Chris Sells. So I still have 3 days to decide if I want to participate!

Paul Krill announces that Microsoft readies specifications compliance kit for Web services. It seems that with those tools in place the stage is set to build entirely standards-based groove clone. That would be a secure (WS-Security) data sharing (WS-Attachments) that can work though firewalls (WS-Routing). Of course this is highly speculative. Need to learn more about this...

Brian Fonseca writes about application-level firewalls.
My prediction: there's absolutely no choice for firewall vendors to go in this direction. Web Services would represent a major target for attack. The richer services become, the more attack-prone they will be. The pain will only start with 'corporate' web services, but sprread on personal workstations as people employ more and more P2P tools.