“The only open source collaboration solution to offer
workflow” (Source)

I know. I had to read it twice.

Maybe Kablink defines “open source” or “collaboration” or “workflow” differently than I do. But solutions like Plone, Drupal, and Alfresco have had workflow of some kind for quite a while. It isn’t like there’s just one other open source collaboration offering out there with workflow, there are several. I’m not sure how Kablink thought they’d get this one past anyone. Maybe they’ll comment here to attempt to justify their claim.

To me, Enterprise 2.0 is the new and preferred way to implement KM. The problem with past KM approaches was that it was too structured, too top-down. Heavy-handed, overly-rigid, formal approaches to anything rarely succeed. They usually end in rebellion, or, at best, apathy. Sharing knowledge because you are passionate about it and because you want to do it is a lot more fun, rewarding, and meaningful than doing it because it is a bullet point on your yearly review.

Formal KM initiatives I saw succeed Back in the Day did so because there were a small number of people within an organization who were paid to shepherd the information as their full-time job. This might have been a corporate librarian or an SME tasked to manage and grow a community of practice, for example. What we now know and what we now have the capability to leverage practically is the power of the network fueled by ubiquitous connectivity, massive storage capacity, and ever-increasing processor speeds that can index the whole mess. Knowledge management at that kind of scale can’t and won’t wait for you to figure out what your taxonomy needs to be. And you don’t need to figure it out–The taxonomy will just be.

It’s not all about the technology. Yes, the tools are better. But Enterprise 2.0 does better at KM not just based on the technology alone. It’s because Enterprise 2.0 is the anti-KM. It’s bottom-up. It has little or no structure. It’s about forming loose and accidental connections with others. If there are potential barriers to KM success this time around, I think it is that, for some types of organizations, this organic, bottom-up approach is antithetical to their current corporate culture. If they can’t change that–and it is so difficult to do–I think they’ll lose competitive advantage and become unable to compete effectively over time. For some, they’ll realize this too late, like maybe the day after all of the Baby Boomers decide to retire and move to southern Florida.

The problem with today’s event sites is that they are too focused (live music, social gatherings, etc.) and too isolated (people have to sign up to use them, they are really only used for RSVP-ing, etc.). I’ve also found that finding interesting events can be tough. I think Meetup.com is a particularly bad offender–they’ve got a weird taxonomy thing going with their events. Their search doesn’t appear to be full-text indexed across meetup names or descriptions. Try to search meetup for “Alfresco”, for example. Although I know there are multiple Alfresco meetup groups out there, you won’t turn up one with a keyword search even with your search scope set to “100 miles of USA”. And when you create an event, it seems like there is a limited taxonomy for categorization. You have to decide if your meetup is about “Software” or “Technology”. Why would I pay them to host an event no one can find attended by a set of people who’s profiles I can only leverage in the context of meetup.com?

This is a sticking point for me. We all belong to different communities with different interests. And sometimes those overlap. Our social graphs shouldn’t be in silos. Neither should the events we attend. Managing your connections across networks together and exposing events to sub-sections of your connections (or across your entire network, regardless of where it is hosted) is really powerful. After all, as Bob says, it is through these events by which we form and strengthen those connections in the first place. Hopefully, this is what you’ll be able to do with Ringside.

His post got me thinking about what I might like to do with events in my own community. So here’s a list off the top of my head. Maybe Bob will comment on how/if this maps to the Ringside roadmap.

Attend/host flag & security settings. An individual ought to be able to publish an event, make public/private settings about that event, and indicate whether they are attending or hosting the event.

Event matching/de-duplication. What would be great is if there was a way to match up events. If I say I’m going to a Wilco concert, and you say you’re going to a Wilco concert, there needs to be a way to figure out if those are the same event.

In-network/same-event notification. Once you figure out two events are the same, people in the same network can discover the fact they share similar interests. The system should facilitate this kind of thing.

Targeted event promo. You should also be able to publicize an event to particular cross-sections of your graph. I might want to host a Ringside meet-up that only goes to my open source/E2.0 friends without spamming my family about it.

Interest level indication. An individual ought to be able to specify whether they are thinking about attending an event or are definitely attending an event. For example, someone might post an event they would only go to if someone else from one of their networks is also going.

Events as tags. Obviously events integrate with the rest of the model. Activity feeds certainly have to know when someone attended an event. But you should also have the ability to tag any item with an event. A photo library app needs to be able to let users tag photos that pertain to certain events, for example.

Event discovery. Events should be easily discoverable by tag/topic, full-text keyword search, by geography, and by attendee. I’d like to see a mash-up between Dopplr and an event database, for example, that knows what kind of events I like to attend and then cross references that with my travel schedule so that if I am traveling to San Francisco, and one of my favorite bands happens to be playing, the site can let me know that, including which of my friends might also be planning to attend (or would attend if they knew I was going to be in town).

Slice-and-dice RSS subscriptions. I should be able to get an RSS feed for each of the following: All events happening in a particular cross-section of my social graph, all events happening in a particular tag/topic, all events in a geography, all events in a particular date range, all events attended by a particular individual in one of my networks, or any combination of these (Live music shows happening in Dallas that my friend Jim is going to).

RSVP options. People should have the option of whether or not to track attendance to an event. Even for an event they are not hosting, they may or may not care who else is attending.

Configurable reminders. People need to be able to choose whether or not to send reminders to attendees. Attendees need to be able to opt out of receiving reminders.

Event ratings, comments, and UGC. People should be able to rate, comment on, and upload content related to an event.

Flexible event types. Events don’t have to be of any particular type. An event is really just a span of time during which something that might be potentially interesting to others is happening. “I’m going to Taco Bell for lunch tomorrow” and “I’ll be spending an hour in the Ubuntu forums Saturday” are both legitimate events that people might want to publish.

Calendar view with the same filtering capability as the “slice-and-dice RSS feeds” requirement. And the calendar ought to be widget-able so that anyone can embed it on their own site.

Standard calendar options for events including start and end time, duration, “all day event”, recurring event. I guess if the event was (or could be exported as) an iCal compliant piece of data that might be enough?

Who’s bringing what. Obviously everyone is familiar with the concept in a social gathering (You aren’t the guy who always just brings the chips, are you? Come on, make an effort, man). But this is also relevant to professional events, particularly for “un-conference” or bar camp type events where attendees are expected to present.

What about an ecommerce component? Maybe you ought to be able to sell tickets for an event. This could open up a can of worms regarding capacity, tiered pricing and availability, ticket authenticity verification, etc., but it might be cool/fun to provide something that could loosen the stranglehold a small number of vendors have on the “live event” market. Just a thought. At the very least, if an event requires a charge, you should at least be able to link to a shopping cart somewhere.

We haven’t made the official announcement of its availability yet, but so many people have asked me about it after seeing the presentation, I thought I’d spill the beans, at least for faithful ecmarchitect.com readers.

Read more about the project and download the AMP from code.optaros.com. If you see things that need fixing, create a bug report or fix it yourself and contribute it back. Have fun!

I’m not crazy about the JCR API because it is Java-only (yes, I know there are bridges out there). Plus, it doesn’t seem to be rich enough for many types of implementations. For example, Alfresco is a JCR-compliant (Level One) repository, but you don’t see too many people doing JCR-only interactions with Alfresco.

What is interesting to me, though, is the idea that you can abstract repositories at a higher level: the REST API. If we’re all going to talk to our repositories via REST, why not do it in a standard way?

Alfresco introduced a REST framework in 2.1 called “web scripts” (learn more). But Alfresco does not yet have a full-blown “REST API”. Yes, there are a few out-of-the-box REST calls but for the most part, when you interact with Alfresco via REST you are going to roll your own API. On Optaros projects, this has not yet been a huge burden. Quite the opposite, in fact–we’ve been able to develop everything from web script-backed JSR-168 portlets to a streamlined version of the Alfresco web client (soon to be released as an open source project), all on web scripts.

As part of 3.0, Alfresco anticipates rolling out additional out-of-the-box URLs to more fully establish the REST API. The new 3.0 web clients are based almost entirely on REST so they might as well build a REST API that we can all use.

When I look at Apache Sling, I’m thinking, why don’t we agree on a standard REST API for working with content repositories. Then, we could write a front-end once and theoretically use it with multiple back-end repositories. If someone then wants to use a JCR-compliant repository behind the scenes, then that’s cool, but it isn’t a requirement.

Obviously, there is a granularity challenge here. If the API is too granular the front-end ends up making too many calls. If you are aggregating multiple calls from within an intermediate application and then returning the result to the front-end (rather than making a bunch of AJAX calls initiated from the browser client), that’s not as much of an issue. If the API is too coarse, it is too hard to reuse across many different types of front-end applications.

Still, if we agree that REST is the preferred interaction model in the “content as a service” world, at least for the moment, and further, that front-end developers tend to want to have the option of using non-Java technologies for the presentation layer, a standard REST API for interacting with content repositories makes sense, whether that’s Sling, whatever Alfresco comes up with, or the best of both.

Maybe the Atom Publishing Protocol is close to what I’m thinking here. Maybe Alfresco thinks so too. I noticed the Abdera JAR was added to the Alfresco Community dependencies fairly recently. Abdera is an Apache incubator project for working with Atom.

We actually have an engagement with Alfresco right now to develop some of the new 3.0 web client modules. When I get some time I’ll explore this idea a little further by checking in on the 3.0 web client team, looking at Abdera, and doing a deeper dive on sling.

Of course the market is relatively small and incestuous and everybody’s gotta have a former employer, but I know when someone leaves you always want to know where they are going and if it turns out to be a competitor, it puts a pit in your stomach.

I guess as the legacy commercial ECM vendors get taken down by Alfresco and, more generally, the open source movement, this kind of thing is going to happen and it will get even worse. It’s kind of like watching Animal Planet. You see the tiger stalking the gazelle, you know what’s coming and you know it is the “circle of life” and all of that, but when the claws inevitably sink into those fleshy hindquarters, you still have to feel something for the gazelle, even if only for a moment. At least until you realize that’s what the gazelle gets for not embracing open source.

Of course hiring a bunch of folks from the same company doesn’t always work out for the best. People tend to be loyal and they move in packs (don’t worry, no one’s getting eaten in this metaphor). For example, someone recently connected the dots for me with regard to the Alfresco WCM engineer departures. It turns out Kevin Cochrane, Britt Park, and Jon Cox all came over from Interwoven so the timing of their departures is not coincidental at all.

The deck covers a bit about the general components of Enterprise 2.0 solutions and how a repository like Alfresco can be central to that architecture because it is so open. I then give a brief intro to web scripts (recycled from the talk I gave at the user conference in San Jose earlier this year) and walk through Endeca and a few other client examples.

I’ve also got some Alfresco-Ringside thoughts in there that include screenshots on the Alfresco-Facebook demo app running on Ringside and a list of potential features that might be interesting to implement with an Alfresco-Ringside combination.

Finally, I’ve got some never-before seen screenshots of the yet-to-be-announced Optaros-built streamlined Alfresco web client which we will release as an open source project under the GPLv3 soon.

It always seemed odd to me that Kevin, with his strong Interwoven background, was driving both the WCM and DM side of the platform. It seemed like a lot of scope to bite off, particularly with the potentially diverse set of use cases each provides. I guess The Two Johns agreed–they’ve decided to backfill Kevin with two resources: Mike Farman for ECM and Michael “Uzi” Uzquiano for WCM. Uzi earned recognition of late with the creation of the “next generation” web site framework which ultimately was adopted into 3.0 and incorporated into the plans for the new 3.0 web client, so he’s got the technical chops.

It’ll be interesting to see what happens next. Kevin’s is the latest departure from the Alfresco WCM ranks. A month or so ago two senior WCM engineers, Jon Cox and Britt Park, left. There seemed to be a bit more proactive damage control being done when Jon and Britt left, but I’m not going to read anything into that.

Alfresco has a lot of momentum right now with key clients going live on both the DM and WCM side of the house, impressive subscription revenue growth, and a good team to fill the void left by Kevin and Co. Provided the 3.0 release doesn’t slip too terribly far behind, I don’t think these departures are going to derail them.

Why does this matter? When you post a multipart form (i.e., a file upload) in a Facebook app, you don’t post to the canvas URL, you post to the application directly, which in this case is an Alfresco web script. All other posts go through the canvas URL and by the time they arrive at the web script, the request has the parameters it needs to make Alfresco’s Facebook web script runtime happy. In Ringside, the file upload post lacks that context because the hidden fields are missing. Alfresco needs those hidden fields–without them, the script has no idea which Facebook app is posting the data.

The fix was easy enough. I just inserted the hidden fields into the form via the Freemarker template (adddocdialog.post.fbml.ftl). The “facebook” root object knows the user, API, and app ID because the form gets displayed as the result of a canvas post.

Here are the hidden fields I added to form in the Freemarker template:

<input type="hidden" name="fb_sig_user" value="${facebook.user}" /><input type="hidden" name="fb_sig_session_key" value="${facebook.sessionKey}" /><input type="hidden" name="fb_sig_api_key" value="${facebook.apiKey}" />

The only other change I made was to comment out the postUserAction call in adddoc.post.js. I’m not sure that’s supported yet in Ringside. If it is, there’s some other problem causing it to choke.

So, other than the user action post, the Alfresco Document Library Facebook app is fully-functional in Ringside.

The next step is deeper integration into the web client. I know Alfresco is moving toward more social networking features in the 3.x release, but integrating with Ringside via web scripts might be a way to get there faster with more functionality.