Flock Ditches Shadows Bookmarking Service

Next Story

Treo 680 Video Love

In a blog post yesterday, Flock’s Mike Dosik announced that they will no longer support the Shadows bookmarking service (Shadows is a product of Pluck) in the upcoming Flock 2.0 release. A number of angry Flock users commented on the post, wanting to know why.

Co-founder Geoffrey Arone stepped in with an explanation:

“Shadows is owned by the Pluck Corporation, who is doing quite well in their core business focused around social media. However, they have decided to de-emphasize the Shadows bookmarks product to focus on their other products.”

This looks to go beyond a simple partnership expiring – Pluck has been phasing out consumer facing products for some time (they announced their RSS reader will be shut down in January 2007) in favor of its new Blogburst publishing platform. In an email exchange this evening, Pluck CEO Dave Panos told me that Blogburst is “getting 100% of our attention” and “we haven’t added any new capabilities [for Shadows] since this Spring.”

That leaves Flock users with just one choice for social bookmarking: del.icio.us. Something tells me they’ll make do somehow.

And Shadows, which we note seems to have a 20 second load time this evening, enters the TechCrunch DeadPool.

More Flock coverage here.

  • Thoralf Will

    I love Jira and Confluence (their wiki product). They are really customer focused and listen when other companies just follow their own agenda.

    The customer support is pretty good as well and stays on the case until it’s really solved.

  • http://www.opscode.com AJ Christensen (fujin)

    I’ll have to get our systems updated, 4.0 looks great.

    Using Atlassian products gives me an awesome level of product integration between ticketing, wiki, review and CI, not to mention tasty API’s. Managing the Chef community wouldn’t be an easy feat without it.

  • http://blog.shonzilla.com Shonzilla

    What is the version of OpenSocial specification implemented inside JIRA 4.0 contains? I also wonder if it’s a full implementation of a OpenSocial container (e.g. does it include RESTful API).

    I couldn’t find this info anywhere.

    • http://crunchbase.com/person/nik-cubrilovic Nik Cubrilovic

      ill find out

  • http://wir-sprechen-online.com/2009/10/06/jira-4-0/ Jira 4.0 « Wir sprechen Online.

    […] OpenSocial will be integrated in issue management tool Jira 4.0 released by Atlassian tomorrow; http://j.mp/1vhnWL […]

  • http://atlassian.com Christina Bang

    Hi Shonzilla,

    Yes. This page might help: http://bit.ly/40XYMk

    • Thoralf Will

      What’s the point of using shortened urls on a normal blog? I can understand it in Twitter (and pretty much only there) because the amount of characters is limited but beside this it’s quite annoying when you see a link and don’t know where it leads to.

    • http://blog.shonzilla.com Shonzilla

      Thanks Christina for the link.

      They seem to be supporting all OpenSocial APIs. Though, there’s no information about the supported OpenSocial version. Either official statement will appear somewhere or someone will need to peek into JAR files. :-)


  • http://entreprise20.fredcavazza.net/2009/10/06/votre-entreprise-a-aussi-besoin-de-community-managers/ Votre entreprise a aussi besoin de community managers > Entreprise 2.0

    […] De ce point de vue là, les services RH ont certainement beaucoup de chose à apprendre des initiatives menées par les services marketing ou com’ dans les médias sociaux car l’expérience est assez proche (même si les utilisateurs des médias sociaux et d’outils d’E2.0 répondent à des motivations / objectifs différents) et parce que les bonnes pratiques sont les mêmes (cf. Twelve best practices for online customer communities). Idem pour les solutions, Atlassian propose ainsi une compatibilité OpenSocial des applications de sa solution de collaboration JIRA : Atlassian JIRA 4.0 Released: OpenSocial Comes To Enterprise. […]

  • http://jnolen.com Jonathan Nolen

    Hi all,

    I’m one of the developers who worked on the Atlassian OpenSocial features. Here’s the scoop:

    * In JIRA 4, we’ve used Shindig 1.0 (Java version). So that means we support version 0.8 of the open Social Spec. (Sorry, but version numbers in OpenSocial-land are quite confusing.)
    * in JIRA 4, our first OpenSocial release, we started by focusing on the Gadget features, including all of the APIs necessary to support those.
    * JIRA 4 does not yet include the person, activity or app-data features. My team is working on those right now, and our next release will include them.
    * The next step after that is to move forward to a newer version of Shindig, which will support either v0.9 or v1.0 of the Open Social Spec.

    The OpenSocial work we’re doing will eventually filter into all of Atlassian’s products. Confluence is up next. We’re making a big commitment to this technology, and plan to keep investing in it as time goes on. So far it’s working out really well.

    Hope this helps, and feel free to contact me directly if you have any more questions: jonathan at atlassian dot com.


    • http://blog.shonzilla.com Shonzilla

      Hi Jonathan,

      Thanks for the detailed info! I’m looking forward to using JIRA 4 and its OpenSocial features. Currently using an old version (which works fine, thank you).

      Where are you hosting your gadgets XML specifications?
      I’m expecting that JIRA gadgets users should be able to use from other OpenSocial containers as well.

      BTW, versioning around OpenSocial APIs and Apache Shindig seems complex but it’s really simple. Standard and its reference implementation being Shindig have different lifes. For example, Shinding 1.1 implements OpenSocial 0.9 (gadgets, JavaScript API, REST and RPC protocols).

      The versioning issue is the same as with web browsers – i.e. FireFox and other browsers are not in sync with either version of HTML or JavaScript specifications.


      • http://www.atlassian.com Tim Moore


        Gadget spec files are actually served from each JIRA instance. They are automatically populated with the URL of that instance, so less configuration is needed when installing the gadget into a container.

        Tim Moore
        Atlassian Developer

      • http://blog.shonzilla.com Shonzilla

        Hi Tim,

        Cool, I understand.

        I believe Atlassian would make life easier for other OpenSocial containers if you used publicly available gadget specification XML files which translates to well-known URLs.

        Some OpenSocial containers (or is it the majority?) have a gadget review process where the accepted gadgets are bound to a known identity (i.e. gadget spec URL). With locally hosted gadget spec files (where URLs vary with each JIRA 4 installation) it is almost impossible to use them in such external OpenSocial containers. However, I believe that using public gadget spec files would be rather easy to implement while retaining the user-friendly gadget installation process for users of JIRA 4 as well.

        The only counter-argument I can think of (after sleeping to little this night) is that you might have a challenge supporting various gadget versions in different installations of JIRA 4.0 (and beyond). By “supporting various gadget versions” here I mean having either different feature sets within gadgets or using different OpenSocial API version or both. This problem is typically solved by versioning gadget URLs or applying any other popular approach of versioning REST/SOAP APIs.

        To conclude with a question:
        Would you consider supporting (or completely switching to) public gadget spec files for Atlassian OpenSocial gadgets?


  • http://www.atlassian.com Tim Moore


    In our circumstance, where individual customers our installing JIRA on their own servers and networks, switching completely to public gadget specs isn’t feasible. Many of our customers have high-latency internet connections, and some are even running JIRA on internal networks that are completely disconnected from the internet.

    It would be possible to provide alternative, centrally-hosted variants for use in other OpenSocial containers, but we decided not to do this yet, for a few reasons.

    One is the versioning issue that you mentioned. Yes, it would be possible to address this by using different URLs for different versions of JIRA, but there are still some challenges there. We’d need to submit each version to social networks to be reviewed, and then we’d end up with multiple entries in their gadget directories. It would be up to JIRA users to figure out which entry is the right one for the particular version of JIRA they’re using. We’re hoping that this issue is eventually worked out at the spec level. There’s a proposal on the table to create a built-in mechanism for versioning applications, but it still hasn’t been officially accepted into the OpenSocial spec, and as far as I know, hasn’t been implemented widely. (http://wiki.opensocial.org/index.php?title=Versioning_Applications)

    A second reason is that we’d need to make some adaptations to the gadgets we ship with JIRA in order to make them work as statically-served, centrally hosted gadgets. As I mentioned earlier, we’ve come up with a way to automatically set the base URL of the server a JIRA gadget is served from. This lets gadgets “phone home” to retrieve data from JIRA via REST without having to be configured to find the JIRA instance it comes from. In order to support centralized hosting, we’d need to make it possible to configure each gadget to find the right JIRA server. Aside from requiring us to fork the gadget spec files to create self-hosted and central-hosted versions, it’s also a bit of a burden on users, if they want to use several JIRA gadgets with the same server, to have to enter the base URL for each one. This is another issue that we hope is eventually addressed at the spec level: the ability to define a set of related gadgets that are all logically associated with the same application and can share configuration.

    Both of those issues have technical solutions that we could work through, however, so the main reason why we haven’t made central, public gadget specs yet is that we’re honestly not sure whether our customers would find it useful. Since OpenSocial and gadgets are pretty new not just to JIRA and Atlassian, but enterprise applications in general, we’re still discovering how they will be used in practice. We’ve seen people interested in using JIRA gadgets within iGoogle and Gmail (or their equivalents in Google Apps) and Google’s implementations do allow you to add gadgets without going through review. We’re also seeing the emergence of other behind-the-firewall enterprise apps that support OpenSocial and gadgets, and we’re working with their vendors to ensure that they interoperate properly with JIRA gadgets. We see a lot of power in using this technology to connect applications that used to behave like self-contained silos.

    All of this is a long-winded way to say that we’re not currently planning to offer centralized public gadget specs for JIRA, but we’re constantly re-evaluating and want to hear where users and developers are interested in taking this tech. If you have specific containers that you’re particularly interested in using with JIRA gadgets, please let us know. I’ll keep watching this thread, or you can email me (tmoore at atlassian dot com) or create issues at jira.atlassian.com.

    Thanks for your interest! We’re really excited to see this community opening up and look forward to being surprised by how creative people use gadget technology.


  • http://www.techcrunchit.com/2009/10/15/nuxeo-releases-ecm-product-with-opensocial-capabilities/ Nuxeo Releases ECM Product With OpenSocial Capabilities

    […] 5.3 can be used as an OpenSocial container, allowing for enterprise mashups with products such as Atlassian’s Jira, as well as being a publisher of […]

blog comments powered by Disqus