Craig Cmehil, Ethan Jewett and I had an interesting conversation (over Twitter, natch) earlier today about demand for New Web tools like Twitter, social networking, social bookmarking inside the firewall.
Twitter’s 140 character limitation sometimes leads to convolution, but I think the core question was how do you approach internal demand for these tools? From the outset, AppsLab has been evangelizing participation as the path to understanding. The big problem is how to get people to participate. I’ve observed four types of people thus far:
- This is old news dude. I already use Facebook to stay in touch, and I tweet from my iPod Touch while I’m on wi-fi at the airport. I have a cron job to tweet that I’m sleeping when I’m sleeping.
- This is really great stuff. I participate as you suggest and join Facebook and build a network.
- This seems useful, but I’m too busy to try these consumer sites. Bring value to me and my daily work, and I will participate.
- No response. This person is either way too busy to participate or thinks I’m a complete tool.
The majority lies in the third group, the hidden demand. So, we used the Field of Dreams theory to tap this demand with Connect, i.e. “if you build it, they will come”. And they did, and after a while, you can’t delineate between the first three groups because many of them participate in both internal and external networks, which is great.
But then you start to get feature requests, and this is where our conversation started. Initially, it was about the merits an internal version of Twitter, like a white-label version or a clone inside the firewall. More broadly, the question is which is most successful inside an enterprise:
- Using the external version, i.e. congregate on Twitter or Facebook. Why reinvent the wheel?
- Deploying a clone for each web app, either Open Source (e.g. Pligg) or homegrown (e.g. IdeaFactory). This provides intranet security baked into roughly equivalent functionality.
- Deploying a platform clone and using it to add functionality, e.g. Connect. This allows you to expose a single network to other web apps.
Each method has its advantages. Broadly, we advocated the above methods like so: Ethan 1, Craig 2, me 3. That’s not to say we disapprove of the other methods, it’s just an observation of how it seemed to me. Let’s look at each in a little more detail.
Using the external version
I don’t know what Ethan does, but I think Craig and I do similar things, i.e. internally evangelize new web. If I didn’t do that, I’d probably follow this path too. Why would I use an enterprisey version of the consumer original that works for me? I’d collaborate with others who work with me and push others internally to do the same, following the “don’t do anything stupid” rule.
Deploying a clone internally
If you’re doing something inside the firewall, you get the old argument about portals vs. sites. It’s funny because I don’t really care for portals on the Interwebs, but inside the firewall, I like a portal better. This is due to speed of information retrieval. I know my way around Interwebs better than the Intrawebs.
So, I’m less likely to use ad hoc internal tools. Craig mentioned he was working on an intranet clone of Twitter, but he bemoaned the duplication issue. The only compelling reason to duplicate a perfectly good external tool like Twitter is so you can protect proprietary information. Because of this, some cloned tools are wildly successful, e.g. wikis, others could be if they’re used a lot, e.g. Pligg, bookmarking, others, not so much. I’d throw Twitter in the last bin.
Deploying a platform internally
If you look at what tools succeed when deployed individually, you’ll see why a portal or platform approach is what we chose. If the intranet is littered with wikis , news aggregators and blogs, bringing them all together is ideal, especially if you can add value to build a large user community. Consolidation of tools and information is the primary value add inside the firewall, plus the baked in security.
We couldn’t bring them all together, but Connect builds the network. We’re slowly adding features to the network, like bookmarking and tagging, another example of a feature that I think will be more successful as a network add-on than as a standalone feature.
I guess my point is that new web tools require a network to get the full benefit, so why rebuild the network every time? I like the other approaches, but they don’t include the network right away.
Of course, one problem is overloading the platform with apps, which circles back to the origin of the conversation, i.e. a Twitter clone. Personally, I don’t think the people that ask for a chat widget would use it enough to justify the investment. Ditto for a Twitter clone built in to Connect, but that’s why we have voting on ideas.
Anyway, this is the type of discussion we plan to have at The Working Group, what works, what doesn’t and why. Once again, the group isn’t an Oracle thing, it’s meant for practitioners.
I like the conversation effect of Twitter. I doubt Craig, Ethan and I could ever have had this exchange in any other forum. Obviously, 140 characters isn’t always enough to make yourself clear, so if I’ve misrepresented Craig and/or Ethan, let me know in comments.
Sound off about your opinions in comments. What works for you and why?