This guest post was written by Jay Simons. Simons is Vice President Sales & Marketing for Atlassian, the developers of JIRA, and issue tracker for IT project management, and Confluence, an advanced enterprise wiki. Previously he was a marketing executive for BEA Systems and Plumtree Software.
A year ago Atlassian decided to make a substantial technology investment in OpenSocial . Many of you may remember OpenSocial as a somewhat obscure technology Google open sourced, in part as an effort to “out open” Facebook and conquer the consumer social web. Two hundred and fifty million Facebook users later, OpenSocial hasn’t really accomplished that, but it has matured in unexpected ways – mainly around enterprise computing. The past year has seen dozens of enterprise software companies introduce support for OpenSocial. (Several of them even did a very “enterprisey” thing and wrote a white paper about it .) At Atlassian, we think OpenSocial is an enterprise technology to watch – which is why we made that bet a year ago. As OpenSocial continues to gain steam, here are five reasons we think it’s important for enterprise software companies and their customers.
1. Componentize applications through Gadgets
As much as every application wants complete control over eyeballs, the Internet has taught us all a very valuable lesson about componentization. Users often want to take valuable pieces of one application and put them into a different one. In our case, our users wanted to simply blend five of our products into a single experience that differed by role. Some wanted that experience in their mail client, some wanted it in JIRA – the system of ours they used most – some wanted it in yet a different tool we offered. Gadgets gave us both a simple way to deconstruct our applications into portable components and a standard container to reassemble them into views. And because Gmail and iGoogle are already OpenSocial containers we got two additional containers our customers could put our stuff into free. As OpenSocial becomes more prevalent in the enterprise, our customers will have more opportunities to mix things together.
2. Easier for developers
OpenSocial is based on the common technologies that make the web work – HTTP, HTML and XML, RESTful APIs – which means the barrier-to-entry for most developers is a lot lower. In our example, this meant that we could bring our own developers up to speed faster and turbo-charge community developers by leveraging the web-technologies they already know. OpenSocial Gadgets are well documented, and there are plenty of resources on the web to help developers get started.
3. Broaden your developer ecosystem
One mark of a great company is the size of its developer ecosystem. Apple, Salesforce.com and even Twitter are great examples. The easier you make it for developers to contribute to your products, the better chance you have at recruiting more of them. Gadgets are dead simple to develop. While you still need to learn the underlying APIs of the system you’re trying to pull data from, Gadgets simplify the method of displaying, publishing, syndicating and securing what you’ve built. This allows developers to focus their energies on a smaller set of challenges. Plus, adding support for OpenSocial gadgets gives you access to hundreds, if not thousands, of developers who already know how to build an extension type your product supports. And your customers probably have developers on staff that have either written gadgets, or already know how to. Huddle bet on OpenSocial for this reason, and also as a way to get functionality added to their products that they didn’t have time to deliver themselves.
4. Social data interoperability
Sharing social and profile data between systems also holds a lot of promise. Most enterprise apps may not seem “social” but nearly every application creates a network of relationships between people and stuff that may be useful. Take one near and dear to us – the “bug” or software defect. There’s an implicit social relationship established between the customer who reported the bug, the developer assigned to fix it, the quality assurance person checking it, and everyone else involved in troubleshooting, developing or waiting on a fix. Those relationships – and others like it from CRM, ERP, HR or collaboration systems – are valuable, and other systems might benefit from them. I might, as an example, want to share the people linkages established in an issue tracker with the system used for online documentation, like SharePoint, Jive’s SBS, or even our own collaboration tool, Confluence. Then the same people brought together to troubleshoot an issue in one system could collaborate together in another on the knowledge base article that documents the fix. And what about sharing activity between those systems? It might make sense for a Sales Engineer to see that his lead in Salesforce has just submitted a bug report or left a comment on the wiki. That’s another area of focus for OpenSocial and the ActivityStrea.ms specification that offers some exciting possibilities.
5. Increase the size of your R&D team
Lots of smart people, from smart companies, are driving OpenSocial forward – from Google to Cisco , with all shapes and sizes of companies in between. Selecting OpenSocial gave us access to this pool of innovators, and meant we could invest our innovation energy in other places. We still focus directly on making OpenSocial better for us, and we think those investments will help other companies working with the technology, just as we hope to benefit from the work others are doing. Not everything will be useful, but generally we believe the rising tide will raise all ships.
We’ve had a great experience so far with the technology, and with the growing community of collaborators – from LinkedIn to IBM. If you’d like to learn more about what we’re doing, check out http://www.atlassian.com/opensocial, and if you want to get involved with the OpenSocial community, visit the OpenSocial “get involved” page .