"The makers of Groove and SharePoint designed them to address different customer needs, and their resulting architectural differences are more complementary than competitive. Groove was designed to support personally-controlled collaboration in an edge/client-distributed model (with optional enterprise integration), readily supporting secure collaboration among decentralized, dynamic teams. SharePoint primarily is focused on enterprise collaboration with a more document-centric, centralized architectural model. It’s worthwhile to look at the ways in which Groove and SharePoint are similar, how they differ, and to summarize the current and likely future Groove/Microsoft relationship from a customer perspective."
Vattekkat Satheesh Babu asks, is a blog a good tool to keep partners up to date on project status?
Joshua Allen: Leaf Nodes
"Ray Ozzie reacts to Don Park’s comment that "A CEO is not likely to know about about, let alone subscribe to, a lowly QA engineer’s blog." Ray is basically arguing that CXOs do want to know what is going on all the way down to the leaf nodes of their organizations, and many of them will use whatever available means to build the clearest possible picture. […] I think Ray hit the nail on the head by pointing out that CXOs have to stay involved and close to the game, or else they’ll quickly lose grip on what’s happening."
I’m going through that question right now, as we’re forming a new company, defining our precise purpose and goals, putting in place a management structure, and all the things you have to go through during that process. I’m the detail-obsessed guy in the team, being convinced that execution rules and is built upon getting a thousand details right (which need to be hierarchized, some things are more important and deserve more resources and attention than others). And I’m struggling to tune the proper amount of details to share with the other partners, notably our (forthcoming) CEO (we’re completing the paper work, can’t tell more for the moment).
I’m trying to create working documents that both provide us the big picture (through exec summaries and detailed outlines – I’m the "188.8.131.52. Sub Sub Sub Chapter" type) and let recipients drill down to fine-grained details if they need to. I consider myself one of the recipients of my output, both to help me refine my thinking and for follow-up purposes. My ambition is to make sure we all keep in synch and keep track of what needs to be accomplished to reach our goals, but I need to find a way to do that which isn’t self defeating. I can’t drown my partners (with too much information) when I’m trying to help them swim in synch! Can too much visibility be counter productive?
In other words, I’m trying right now to communicate the value of project management to my partners, and to turn it a working practice that is compatible with a small start-up which needs to be flexible and nimble. But I still think this is essential, as a lack of follow-up could kill us. We’re beaming with so many ideas at this point (which is only natural at start-up stage) that we’ll need to keep sight on operational execution. But it shouldn’t look like censorship or ISO 9000-like produceral hell. It’s all about channeling energies, you don’t want to let them scatter nor kill them.
"When you and I engage in conversation, I can’t control how well you communicate; I can only control how well I receive what you’re telling me. I can go on the alert to things that may distort the messages you’re sending me – I call them filters. To be a good listener, you’ve got to know what you filters are. Maybe you’re coming into a given conversation with an agenda. Maybe you’re judging the speaker and don’t trust him at all. Maybe you’re angry. Anyone of these psychological filters can distort what you hear."
This is especially dangerous with "low human bandwidth" tools such as email or IM where you lose all the intonations and non-verbal cues (which led to the need for these silly emoticons). It’s incredibly easy to take an email the wrong way, so there’s only so much interaction you can have through online text-only tools. Even in 100% online-centric projects, the amount of trust required to do business will require partners to work the phone and meet face to face sooner or later (from personal experience, I’d advise sooner than later, it really makes a difference).
Rick Klau provides real-world feedback on an Intranet weblogging pilot, without the simplistic cheerleading sometimes seen on this topic.
"Developers will find GWS [Groove Web Services] to be a textbook example of a style that has come to be called "RESTful SOAP." REST (Representation State Transfer) describes the architectural style of the Web. What that means for SOAP, as recommended in the W3C working draft for SOAP 1.2, is that interfaces should "use URIs [Universal Resource Identifiers] in a Web-architecture compatible way — that is, as resource identifiers.
For example, the root of GWS is a SOAP service with an address like http://localhost:9080/GWS/Groove/1.0/Accounts. Since a Groove account is a container of identities, a Read operation on this resource produces an XML document that enumerates them. Each identity includes an element like /GWS/Groove/1.0/Spaces/grooveIdentity/123…xyz — that is, the URI of the SOAP service that enumerates the shared spaces for that identity. Traversal of spaces, tools, and data proceeds in a similar fashion. It’s all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete."
"Billions are being poured into the FBI and other governmental organizations and they can’t even get the basics right. […] This can be corrected very easily. Give every agent a laptop (shoot, they gave every student in Maine a laptop for Christ’s sake!). Put a weblogging tool on that laptop. Require that they write up a synopsis of every tip or interview they do in their weblog. Have them publish that weblog to a central Intranet. Put a Google appliance on that Intranet. Let it index the pages."
Well, maybe. If you have a hammer, everything starts looking like nails. Someone explains me how people are supposed to navigate the morass that this Intranet would be and actually dig anything useful about John Doe, the suspect they’re interrogating.
"How simple is that? A couple of simple search routines could have netted this information. After that, it would only be a matter of ruling out suspects — which could have been left to local police. A couple weblogs, sorted by region could have been set up to disseminate the most likely leads to local police. Don’t tell me it is more complicated than that. It isn’t."
Sorry but I don’t buy it at all. Do your simple "John Doe Caucasian" query and have fun parsing 18,000 blog results. I have a friend and client who has a quite uncommon name yet I dug out an article about a priest with the same name expressing his tolerance of nudism (at least the irrelevant result was fun in that context). Even if you train thousands of law enforcement agents to do proper search engine queries (which would probably be a good thing to do, but now we’re starting to dwarf the software licensing costs that were talked about), it’s obvious that no matter how great the search of unstructured data is with Google, it’s very far from perfect. If you’re looking at it honestly, many Google queries take quite some trial and error to bear fruit, or just utterly fail.
Besides, Google uses links to assess relevance. Now I really want to see that work in an Intranet context, and I’m willing to bet that the linking critical mass needed to create that layer of content organization will take a long time to reach. The FBI wouldn’t just need to blog their interviews and leads. They’d need to link to them in context too. Google works on the web thanks to its sheer size, i.e. out of hundreds of millions of users, someone will probably have properly linked to the relevant document. And even now, some questions (for instance, technical problems) get a much better yield on Usenet through Gooja than on the web, because of Usenet’s conversational questions-and-answers nature.
Trillian is showing big players what an IM client is supposed to be, and it actually works while I – as well as others I talked to – couldn’t even get Jabber clients to do anything (your mileage may vary).
I like how their stocks plugin let you change the web site you use to get detailed information (provided the site is REST-compliant, you need an URL that takes the stock ticker as an argument).
The RSS plugin is fun but obviously doesn’t scale if you monitor dozens or hundreds of sources, and there’s no obvious way to import a whole list of subscriptions (i guess in OCS format or something). You can float the plugin in a separate window, from the contact list.
The Winamp plugin doesn’t work with Winamp 3.0 yet, but I’m not sure it was such a good idea to install the later. There’s also a plugin to check POP3 email accounts (not IMAP4 as of yet) but it didn’t work for me.
There’s a total of 8 plugins overall, and I don’t know how hard they’re to do, so I wonder if Trillian is about to become a platform as successful as Winamp for third-party goodies.
I’m not a big fan of e-mail for group collaboration, but Jim Roepcke comes with a sensible and detailed counterpoint.