Tag: Add-ons

My Proposal for Resurrecting the Alfresco Add-ons Directory

Friday, May 25, 2018 was an auspicious day. You may remember it as the crescendo in the wave of GDPR-compliance related email notifications because that was the day everyone was supposed to have their GDPR act together. For those of us in the Alfresco Community, it was also the day that the Add-ons Directory died (or, more correctly, was killed). In fact, the two are directly related. More on that in a minute.

First, a quick disclaimer: My team and I created the Add-ons Directory back in 2012 when I worked for Alfresco. I also have multiple Add-ons listed in the directory.

But this post isn’t about being upset that something I created went away. I’m not sentimental about such things. Instead, I want to give some context as to why an Add-ons directory is important, grumble a bit about its abrupt demise, and, more importantly, provide a vision for how we can restore what many of us considered to be a valuable community asset.

Why an Add-ons Directory is Important

From a practical standpoint, I referenced the old Add-ons directory on a weekly basis. Customers and community members would routinely ask about me about functionality like e-signatures, scanning, and multi-factor authentication, and it was useful to be able to point them to the directory to learn more.

From a bigger-picture perspective, an Add-ons directory does the following:

  1. Helps customers extend the platform to close requirements gaps without requiring them to write code or hire developers by making it easier to find existing Add-ons
  2. Matches Add-on seekers with Add-on providers, some of whom might have a hard time getting noticed depending solely on organic search
  3. Provides a mechanism for the community to give public feedback on Add-ons which the developers can incorporate to improve their offerings and the rest of the community can use to help judge whether or not a particular Add-on meets their requirements
  4. Can form the foundation upon which a marketplace can be built to facilitate monetization of Add-ons, trading value (dollars) for resources (useful, quality extensions)
  5. Acts as one potential proxy for the vitality of a developer ecosystem

Over time, customers tend to have very similar requests for Alfresco customizations. Often, the community addresses this by building Add-ons and making them available either commercially or as freely-available, open source-licensed downloads. Without a central directory, the only way to find these is by searching the internet or through word-of-mouth. A directory of Add-ons provides a way to shortcut that search. When combined with social features like comments and up-votes, the community can help spotlight the most useful Add-ons.

A directory can also serve as the foundation for a marketplace. An application marketplace is more than a directory, but it cannot function without one. The old Alfresco Add-ons directory included an RSS feed that the product subscribed to and displayed in the Share user interface which helped give visibility to the directory and newly-created Add-ons, but that’s as far as it got toward being a marketplace. We had a vision that included being able to search for and enable Add-ons from within the Administration panel, but the architecture of the platform and engineering priorities kept that vision from being achieved. We never got anywhere close to being able to facilitate payment for those that wished to do so.

Despite being just a directory, when we launched Add-ons, we watched the number of submissions grow fairly steadily. There were over 500 listed when the site was taken down. This growth motivates everyone in the community: Developers see an ecosystem in which they can participate to market their products and services; Sales people see a way to help close deals by pointing to the activity around the platform and the ability for the customer to close requirements gaps with Add-ons; and Customers are reassured that there really are developers who are investing time and talent in the platform.

Why it Went Away

Alfresco says that GDPR concerns forced them to take down the site. You can read more on that here and here. Assuming the GDPR reasoning is valid, it is a bit irksome because GDPR was a surprise to exactly no one. If the site was a GDPR compliance problem, that should have been identified early enough to put a plan in place for a calm migration to a suitable alternative with plenty of advanced notice to the community. Instead, the site was abruptly shutdown that Friday with hastily-crafted blogs posted after-the-fact followed by a weeks-long effort to restore at least part of the data.

That effort is now complete and the listings are available in Alfresco’s community site here. I’m glad the data was restored, but this can’t be considered a long-term solution because:

  1. When searching for an Add-on you must now wade through results that include both Add-ons and forum threads.
  2. The ability to perform a faceted search is limited to filtering on release.
  3. The old Add-ons RSS feed that is used by the Add-ons Dashlet in the product is still broken and fixing that would be painful because in the community site, each Add-on is now simply a blob of unstructured, static text.
  4. This unstructured listing is painful for developers to maintain and ill-suited to programmatic access, which would be necessary to support an actual marketplace.

Clearly something different is needed and I’ve got an idea that might be the start of something kind of interesting.

A Proposal for Moving Forward

The first thing we need is a way to describe an Add-on that is:

  1. Independent of the directory that indexes it
  2. Owned and managed by the developer
  3. Easily updated via script

The problem of using a generic project descriptor and then ingesting that into a public directory has already been solved. Java projects have a POM file that includes metadata about the author and a description about what it does. That file can be configured to make it easy to publish to Maven Central, a public directory of Java packages. The Node world has package.json and the NPM registry. In Python you create a setup.py file that the public Python Package Index can read.

The Alfresco world needs something similar, so I’ve created a project on Github called alfresco-addon-descriptor. The project contains a JSON Schema for describing an Alfresco Add-on, an example addon.json file that adheres to the schema, and a runnable Java class that validates a JSON file against the schema.

This is a small start of something that could grow. I’m open to suggestions, but here’s how I see it potentially playing out…

Step 1: Get the schema roughly right

I took a swing at the schema but I want your feedback. I don’t think it needs to be perfect–we can version it as it evolves. We just need to get it roughly right for now. Please create a pull request if you have ideas for improvement.

Step 2: Everyone puts addon.json in the root of their project

Once we get a decent draft of the schema in place, we get everyone to put addon.json in the root of their Alfresco Add-on projects.

Now, the description of an Add-on is much “closer” to the developer. In fact, keeping it updated could be scripted if the developer so chooses. This will cut down on directory entries being out-of-date.

If we go no further, at least we’ll have a standard way of describing an Alfresco Add-on that could be leveraged by code and directories in the future.

Step 3: We stand up a simple directory that indexes everyone’s addon.json files

I am happy to do this and would probably run it under the ecmarchitect.com domain. But the beauty of the approach is that anyone that wants to could stand up a directory, all fed by up-to-date entries stored where it makes sense–in the projects themselves.

Developers could submit pointers to their files once, and the system would poll over time to keep them updated. The directory wouldn’t be able to poll closed source projects, but developers could just submit their updated addon.json file whenever it changes.

If I run the directory, I might charge closed-source Add-ons a nominal yearly listing fee to subsidize the operational costs of the directory similar to how Github can be used for free by open source projects while others have to pay a little bit.

If we stopped here, we’d have a more up-to-date and functional Add-ons directory with faceted search and a RESTful API.

Step 4: Support for monetization

Suppose this idea takes off and this new distributed directory of Alfresco Add-ons gets populated by open source and closed source developers alike. The next step is to make the directory a true marketplace.

I know that not everyone wants to charge for software and that some are morally opposed to software licenses. The directory would continue to support open source Add-ons as first-class citizens from day one.

For those that do want to charge for their Add-ons, actually doing so can be a pain. What if it was as easy as describing your cost model in your addon.json file and doing a small one-time registration in the Add-ons site to work out payment details?

On the customer side, what if you could search the directory, then pay for your Add-on subscription with a credit card?

This would make it easier for small and independent developers to get paid, and would remove paperwork and procurement drudgery for everyone.

It is unlikely that Alfresco will ever provide such a service due to the accounting, development, and infrastructure involved, not to mention possible messiness around partner conflicts, supporting a payment stream for non-partner community developers, etc. Plus, it’s just not core to their business of providing content and process services. But an independent directory would have no problem pulling this off. It’s not a big money-making idea, to be sure, but that’s not the point. The point is to restore a community asset, making it better than it was before.

If we make it this far, we will have resurrected the old Add-ons directory and added more features and functionality that benefit the entire community.

What do you think of this idea?

Specifically…

  1. As an Add-on developer, do you like the idea of describing your project using a standard vocabulary and maintaining that alongside your source?
  2. As someone who might want to charge for Add-ons, would this save you time and energy, making it more likely that you would list (or even develop) your Add-on in the first place?
  3. As a customer, do you value having a one-stop shop for finding Alfresco extensions? Or is internet search good enough? If you found a promising Add-on that required an annual subscription, would you pay with a credit card if the service leveraged a trusted payment provider to handle your transaction safely and securely?

It’s a shame the old Add-ons site was demolished so hastily. The good news is we now have an opportunity for a do-over, hopefully without repeating past mistakes, putting the data back in the hands of the developers where it belongs, and restoring a community asset better-positioned for future growth.

 

Keep your users informed with this new Alfresco Share add-on

A common request from clients is the ability to manage a simple set of system announcements which can be displayed on the Alfresco Share login page. These might be used to let everyone know about important events like an upcoming system outage or that there are cronuts in the breakroom.

This is a straightforwaShare Announcementsrd add-on to write, but I thought it might be useful to others, so I’ve packaged it as an open source add-on available on GitHub.

The idea is simple: When you install the module, it will automatically create a folder in the Data Dictionary called “Announcements”. Administrators will create one plain text file in that folder for every announcement. There is no custom content model or properties to mess with. The content of the file is the body of the announcement.

An Alfresco Share Extension Module does the work on the Share side. When a user opens the Share login page, a Share-tier web script calls a new announcements web script on the repo tier that returns the announcements as JSON. The Share extension formats the JSON response as an un-ordered list that gets injected into the login page between the Alfresco logo and the username/password fields.

When you are ready to take an announcement down an admin can either delete the announcement file or move the file to an arbitrary folder under “Announcements” to save for later reuse.

Some installations–like those with Single Sign-On enabled–never see the Alfresco login screen. For those installations, or for anyone that wants to expose the announcements to logged in users, the add-on also includes an announcements dashlet.

Announcements DashletHopefully you’ll find this useful. If you find issues or want to make enhancements, pull requests are always welcome.

A simple one-way calendar integration for Alfresco Share

Photo credit: Dafne Cholet
Photo credit: Dafne Cholet

A common request is to integrate the Alfresco Share calendar with an external calendaring system such as Outlook, Google Calendar, or Zimbra. Without an integration, people end up doing double-entry. You’ve already got a calendar that works pretty well. Why make people re-enter events in Alfresco Share?

Most people use Alfresco Share for team collaboration. The calendar doesn’t need to show everything on everyone’s calendar–that job is better left to the existing calendar server. What makes more sense is to show a few team-related events or milestones on the team’s Alfresco Share site calendar or maybe in a dashlet on the site’s dashboard.

When thinking about the problem, I realized that the calendar in Share is just another interested party in an event. Just as some calendaring systems allow you to “invite” a conference room to a meeting which effectively reserves that room for the meeting, you ought to be able to “invite” a Share site and have the Share site add that event to its calendar and update it when the event changes.

Treating the Share site as just another invitee is a non-invasive way to integrate with the calendaring system and it has the added benefit that only events in which the Share site was specifically invited will show up on the Share site calendar.

As luck would have it, the pieces to make this work already exist and they don’t require any changes to the source calendaring system. Check it out:

  • When you invite someone to a calendar event the calendaring system sends an iCalendar (.ICS) file as an email attachment to the invitee. The invitee’s email or calendaring client recognizes that attachment and updates the calendar accordingly.
  • There’s a Java library called iCal4j that knows how to parse iCalendar files. Yea for standards!
  • Alfresco supports receiving inbound email and you can easily bind custom logic to the creation of nodes. Alfresco creates one document for the email body and one for the ICS file attachment.
  • Events that show up on the Alfresco Share calendar are just content-less objects–they are instances of ia:calendarEvent.

Put those pieces together and a simple one-way calendar integration is born. The integration watches for incoming email with ICS attachments, parses the attachment, then creates, updates, or deletes the corresponding Alfresco Share site calendar object.

With this in place, all you have to do to add an event to the Alfresco Share site calendar is invite the Share site to the event from your favorite calendaring system.

But what’s the invitee name of a Share site? Great question! In Alfresco, there’s an aspect called email alias. You can add it to any folder and give it an arbitrary value. Then, when sending email to Alfresco you can specify the alias.

My integration includes code that makes sure all Share sites have a folder that can be used to store inbound email and it gives that folder an alias equal to the Share site’s short name (which is used as part of the Share URL). So if your Share site is called “test-site-1” and you normally send email to Alfresco via alfresco.someco.com, your Share site’s email address becomes test-site-1@alfresco.someco.com.

What about updates? Calendar systems have a universal identifier for every event. When calendar entries are updated or deleted, the calendaring system sends an iCalendar file just as it does for new events. Included in that file is the event’s unique ID and a flag that indicates whether the event is being created or deleted. When the integration creates the event in the Alfresco Share calendar, it stores the unique ID in the Alfresco object’s metadata which it can use later to match up subsequent update and delete requests.

How about a demo?

This video shows the integration in action. Be sure to make it full screen and select “HD”.

(If you can’t see the video, watch it on YouTube here).

What’s left to do?

This is a simple, one-way integration. It does not tell the corporate calendaring system which sites are available and it does not do a free-busy lookup. It also does not acknowledge the invitation back to the source calendaring system. I don’t consider these to be critical gaps but those features might make the integration tighter.

As a side-note, the automatic creation of an email alias for a Share site and a corresponding folder to hold inbound email (which users could then configure rules for) might be useful as a separate add-on even if you don’t need calendar integration. If you agree, let me know. Maybe the integration ought to be split into two separate AMPs.

Pull requests welcome

As usual, I welcome your participation on this project. If you find problems, fix problems, or want to make improvements, use the github project to create issues and pull requests.

Combine the qualitative and the quantitative with Alfresco and Pentaho

Yesterday we had our monthly Tech Talk Live session. The topic was “Business Intelligence for ECM Practitioners” and it was all about how BI can be applied to the data that lives in your Alfresco repository. We were joined on the panel by Francesco Corti, who is experienced in both ECM and BI, as well as John Iball, the product manager for Alfresco One.

Here is the broadcast in case you missed it:

During the broadcast we saw Francesco’s AAAR solution which extracts data from Alfresco and puts in a data warehouse. Pentaho, an open source Business Intelligence platform, is then used to create a dynamic dashboard that end users can use to interactively answer business questions about that data. Francesco showed a live demo of reporting using Alfresco auditing data, but with his CMIS connector for Pentaho, you could report on anything stored in the repository.

John Iball shared with us that reporting and analytics was one of the top features requested during a recent discussion with 70 or so Alfresco customers. Rather than very basic reporting features, John said that customers want the ability to do deeper analytics on the data stored in Alfresco. Some will already have BI platforms in place. Others will benefit from a complete solution. Either way, John says that meeting this need is high on Alfresco’s roadmap right now.

About Tech Talk Live

Tech Talk Live occurs on the first Wednesday of every month barring a holiday or some other conflict. During each episode, the Alfresco community team focuses on a specific topic and invites panelists from Alfresco, partners, and the broader community to take part in the conversation. The session is broadcast to the public live on Google Hangouts on Air with Q&A taking place simultaneously in #alfresco on freenode IRC. Check the wiki for links to prior and future episodes. The Alfresco events page also has entries for Tech Talk Live.

Our next episode will be on March 5 when Nathan McMinn joins us to recap some of the killer projects that were created during the Alfresco Summit 2013 hack-a-thon.

List of Alfresco Dashlet Challenge 2011 Entries

The Alfresco Dashlet Challenge contest has been over for quite a while and our winner, Florian Maul, has received his iPad and has already racked up some impressive Fruit Ninja scores, but I’m just now getting around to posting the entire list of entries. I’ve put the list on the Alfresco wiki.

Please do take a look at these projects and try them in your own installations. In many cases, it’s a single JAR you drop in, then restart and you’re done. If you find problems, don’t hesitate to log issues or maybe even crack open your editor, fix it, and contribute it back to the author.

I should take this opportunity to mention a little project we’ve got brewing. If you’ve heard any of my “State of the Community” talks you may already know about Alfresco Add-Ons. It’s a site we’re building that will do a better job of helping you find and rate add-ons the community is creating for the Alfresco platform. An Add-On might be a dashlet, like the Dashlet Challenge entries, or it might be an integration, or an API, or just about anything else that works with Alfresco.

Add-Ons isn’t meant to be a project hosting site. There are already a lot of those available. Instead, think of it as a directory or index with some social features to help the cream rise to the top. This will give everyone (Community & Enterprise users) a one-stop shop for add-ons and extensions.

We’re hoping to have a minimum viable product ready by DevCon. If it gets done and enough people want to see it, we’ll have an ad hoc session so we can look at it together. We’d obviously like to get feedback from the community for the next sprint.