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.