Introduction
A few months ago, Aaron Crosman posted What I Brought from Drupal to Salesforce. While I've done a lot of CMS/CRM integration work, I've only been integrating Drupal with Salesforce and its related services for a few years. I still consider myself new to Salesforce development and I'm still learning about the open source side of Salesforce at events like Salesforce Community Sprints.
If I do get something wrong, please let me know and I'll update the posts.
Another reason for writing a series highlighting some of the similarities between Salesforce and Drupal is to respond to a recent post by Jacob Rockowitz questioning whether his Blueprint project that leverages Schema.org had a future.
I briefly mentioned Blueprints in a presentation at BADCamp, but I wanted to dive in deeper into Blueprint as well as some of the other features starting to mature in "modern Drupal" where I've seen similar approaches working well in Salesforce.
To keep myself sane, I'm breaking this up into 3 parts;
- Project Browsing - Project Browser and AppExchange
- Schema Management - Blueprint and Educational Data Architecture
- Advanced Configuration Management - Config Patch GitLab API and GearSet
Project Browser and AppExchange
The UI in the work coming out of the Drupal Association's Project Browser Initiative is very similar to Salesforce's AppExchange (and MetaDeploy, AppExchange for open source and Commons supported Salesforce packages).
Visually, the UX of the Project Browser and AppExchange are very similar.
Out of the box, Project Browser isn't really that exciting for developers.
So I can search for modules inside the application I'm building and then go to Composer to
composer require drupal/[PROJECT NAME]? Why would anyone get excited about this?
The exciting part of Project Browser isn't using it to browse the same projects on Drupal.org in a different UX, it's being able to customize that experience for a specific use case or infrastructure. A feature that gives users a list of projects they can install directly on a test/sandbox version of their site is a game changer in a higher ed use case.
How do I know?
On the CMS side, we wrote something similar to Project Browser the University of Colorado in Drupal 7 we called Profile Module Manager. While the colorado.edu sites are now run from a monorepo/custom upstream approach on Pantheon, the original on-prem infrastructure paired Profile Module Manager with a custom devops solution to add a "bundle" of code to a site's codebase. The user experience of Profile Module Manager within Web Express in D7 and Project Browser with a customized project feed in D10 will be very similar.
Project Browser won't really be exciting until it can be combined with the Auto Update Initiative work. That work requires Composer 2.3.5 or later which many hosts (including Pantheon) do not support yet.
On the CRM side, when browsing packages and clicking Get It Now of free packages will bring up a prompt asking you where to install the package based on instances you have registered with the account you are authenticated with... or to spin up a new sandbox to test just this package.
While Drupal's Project Browser UX is designed to be used with the CMS instance you are planning to install the package on, it's not hard to imagine large, Drupal centric hosts like Acquia or Pantheon offering customized Project Browser feeds that list platform friendly/approved modules.
Modern Drupal still has to define a way to install front end dependencies required by PHP projects. Salesforce solves this to a certain extent with Lightning Web Components, their open source Web Component foundation.
While there is some traction around #2873160 to use NodeJS installer for Composer and #3340712 to get single directory components into Core, this is still going to be a challenge.
It is also important to acknowledge that most packages you can install through the different Salesforce project browsing services are NOT free or open source. Between the AppExchange and MetaInstall services, you'll find 4 different types of packages.
- Free, Open and Transparently Maintained on GitHub - The Summit Events package maintained primarily by staff from the University of St. Thomas at https://github.com/SFDO-Community/Summit-Events-App is a good example code maintained openly with BSD license.
- Free, maintain by Salesforce - The Educational Data Architecture (EDA) is a good example of this. I'll write more about EDA in Part 2.
- Free, Closed Source - You'll find a mix of free loss leader products, feature limited version with a paid upgrade, and free package that requires a service subscription, but the source of these packages cannot be modified.
- Paid, Closed Source - 75% of packages charge. Most use a per licensed user/per month model. Some offer free trials.
Paid plugins are more common in the WordPress ecosystem, but the underlying plugin code is considered a derivative of WordPress where distribution triggers the GPL-2.0 or later licensing requirement.
Where I think this is going to get interesting is the potential for more commercial Drupal packages in SaaS offerings. We've already seen some large hosts charge for value added services for sites hosted on their infrastructure like Acquia Site Studio. We may see more groups exploit the GPL SaaS Loophole enabling customers to install commercial modules and themes from customized Project Browsers.
As long as the end-user is interacting with your software over a network and you control the hardware / infrastructure the software is running on, that is not considered distribution.
While different than traditional, pure GPL Drupal sites, after seeing the quality in competing packages in Salesforce, I personally think a tier of commercial, closed source modules would be good for Drupal.