Drupal Site Template Marketplace MVP Proposal

A lot of questions come to mind reading this, but I'll summarize things into bite sized bullet points for now. My "bottom line up front" is that without more clarity around hard technical requirements, I can't imagine participating until the MVP phase is complete, and without a perpetual "freedom of pricing" guarantee, I would hesitate to participate at all.

A. Items that need more clarity:

1. The biggie will be those "emerging standards" re: recipes, design systems, and XB that I know we don't have yet, so I'll hold my peace in that regard.
2. However, why must a template be an extension of Drupal CMS / use the CMS installer if it satisfies similar objectives? I understood site templates to be for the promotion of Drupal writ large, not Drupal CMS alone.
3. How should accessibility self-certification work when I might include any contributed projects that do not conform or provide configuration options that make it very easy for the end user to violate WCAG standards?
4. Self-certifying GDPR compliance is ambiguous. How do we determine if we are applicable, and to what extent must we support compliance? i.e., is this really the responsiblity of the template creator vs. the end user who believes they are subject?
5. Why can we not patch contributed modules? Sometimes it is necessary, e.g., to incorporate compatibility patches or usability improvements that are in progress in the issue queue but not yet incorporated into a release.
6. Is the prohibition on advertisement in the template restricted to the front-end or also include the back-end? e.g., can I not use the administrative interface to offer support or services to my customers?
7. How can we conduct a performance test in the abstract w/o a production server environment?
8. What scope is implied by “monitor and respond to user-reported issues in a timely manner” when the issue may be a usability, compatibility, or other issue in a contributed module incorporated into the template?

B. Last, some notes on the proposed commercial arrangements:

1. I'd be unlikely to agree to a perpetual revenue sharing agreement. Past a certain point, the continued business of a customer is on me, the introduction having long past. If someone launches on my template, grows on it for two years, and then decides to engage my team on an expensive systems integration project, the current language would require me to send 10% of that to the DA. Not only is that a higher commission than I’ve paid to similar lead generation / referral services, they all had an expiration timeline and were rarely even 10%.
2. It isn’t clear what happens once templates are sold directly through a marketplace maintained by the DA either. Is the 30% perpetual? The 40%? Just the 10% ecosystem support fund? For what it’s worth, I would not utilize a marketplace that cost me 40% even one time - or at least I'd bake that into my pricing and price even higher. Even with an expiration timeline for referral fees, I wouldn’t participate at 30%.
3. I don’t know what a “global pricing equity framework” is, but I doubt I would submit to it. If I have fixed costs for producing and supporting a template, I cannot not be in control of how much I sell my product for regardless of where my potential customer might live or what financial constraints they have. If the DA wanted to cover part of the cost of the product to ensure people had access to it, that’s obviously fine, but I shouldn’t be forced to sell my product at a loss to participate in a marketplace.

Given the proposal mentions the potential for a pricing equity framework, I would need guaranteed pricing autonomy before beginning the formal production process of a template now. I have to work according to some financial model, and while I can scale my ambitions up or down to manage my costs to make my template a better fit for the marketplace, I cannot be told I can sell a template for $1,000 today, incur all of the up front expenses, and then 1 year from now be told I must also make it available for $250 to people in X country or with Y constraints.

Thanks for the thorough review, Ryan! I have a few follow-ups:
A1. Agreed. My understanding is it will be stable by Vienna so that folks have ~5 months before Chicago to

A2. That was the charter for the group as Site Templates are intended for use with DrupalCMS. My assumption is that it has to do with the installer that comes with DrupalCMS and the fact that Site Templates are only useful when starting a new project as a starter kit.

A3. Certification would have to be only for the out of the box experience. We are all aware that client configuration/content can change that and no one certify that downstream.

A4. GDPR would again be a self-certification where the maker could state affirmatively what GDPR compliance features it has (if any).

A5. This comes from DrupalCMS Leadership Team, but may be (too) aspirational. What would be more realistic?

A6. Can you say more about this? There was a strong sentiment against Wordpress-style aggressive/spammy tactics. What would seem appropriate to you? Could any module do that? What about conflicts?

A7. This test would be tbd and performed during the review on submission/annual review. Identifying the suite of manual and automated review tests and it’s my expectation that would be done in conversation with the initial DCPs. The initial pool is small by design precisely because it’s expected there will need to be that type of close collaboration.

A8. What seems reasonable here?

B1. I do think a timebox is reasonable (and expected). What terms would you suggest?

B2. Agreed. This is not the proposal for a marketplace where the DA is hosting the transaction platform and fulfillment. There was a lot of discussion about that option so it’s noted here. I might expect the referral fees would be similar (time-boxed, 10%). The 30% is only for the transactions that occur on that platform (comparable to the Apple App Store). The additional 20% over the initial marketplace with off-site transactions and fulfillment is to cover the ongoing costs of transaction fees and staff customer service time and development, operations and maintenance of the platform itself.

The 10% ecosystem fund came thru community feedback/a desire to support upstream module maintainers.

3. Again, this is noted as it came up, but is not part of the current proposal. The global equity concerns are supply side such as: accessibility of DCP and Marketplace participation costs especially for Makers in non-EU/US countries or solopreneurs, discrepancies in direct costs leading to pricing pressure/unfair competition. Any such framework, should it be proposed and then adopted after community review period, might address who gets to participate, where and at what cost.

In no event would such a framework impact what a maker charges for their site template.

Q: in the hypothetical future scenario, what would hold you back from offering the template via the d.o marketplace at pricing that passed along the costs (e.g. $1500 instead of $1000). There is nothing noted in the policy about exclusivity do you could continue offering it directly (or via other Marketplaces) without the markup.

The proposal doesn't mention recipe browsing at all, and it only mentions project browser once.

Once people have installed a site template (how is not clear from the proposal), they need to be enable optional features on their site - the current recommended way to do that for new users is via recipes. However 📌 [Meta] Plan for recipe Active hasn't had significant updates for several months. 📌 Decide on naming convention on recipes Active is also marked postponed. It's not possible for project browser to browse and install recipes from d.o, and shipping recipes with project templates causes serious problems with dependency management. If that works is happening elsewhere, I don't know where it is and it's not easy to find.

Given that,

The MVP, targeted for launch at DrupalCon Chicago (March 2026),

looks like it's going to directly detract from work that is more important to new user experience - it's like selling phones where the app store can't connect.

Haven't read the rest of the proposal properly, just saw the timelines and what for me is a fundamental missing piece.

Acknowledging your feedback that this proposal does not address (nor was it designed to) the unfinished recipe work. Noted your concern that creation of recipe browsing and project browser-recipe may be a dependency for a Marketplace launch.

Recipe browsing implementation and recipe integration into project browser rest are technical decisions that rest with the Drupal CMS team and I have flagged it for them.

I don't think recipe browsing is a purely technical issue for the Drupal CMS team. There are direct resource constraints and dependencies between implementation of site templates and a marketplace vs. improving package_manager and project browser (and implementing the Drupal CMS improvements that are blocked on those) so that Drupal CMS sites can be hosted and maintained reliably.

e.g. the proposal says:

During the Pilot, the Drupal CMS Leadership Team will manage the pilot onboarding resources and Site Template Makers support.

But more than this, I've had concerns for some time that 'site templates' as a primary category is putting the cart before the horse.

The Driesnote at DrupalCon Atlanta contained a long section about LEGO history, pointing to the creation of branded/themed LEGO sets as driver for renewed LEGO interest in the past few decades.

However, LEGO has notably never (afaik) produced a line of pre-assembled LEGO sets. Let's imagine for a second that they did:

1. It would be incredibly labour intensive to assemble each LEGO set, or require robotics and automation capabilities way beyond most automated car factories.

2. The price of the LEGO sets would be hundreds or thousands of dollars more than a regular one

3. The packaging requirements for these sets would be massive - metre square boxes.

4. They would constantly get damaged during transit - bits falling off the pre-assembled model then getting lost in bits of polystrene

5. Even at the same price, no-one would buy them anyway, it'd take all the fun out of it. If you want something that doesn't require hours of construction for smaller kids, you can buy Sylvanian Families or similar.

Also a big part of the appeal of LEGO is the interoperability - the city stuff or LEGO Friends sets can be combined into mini-landscapes, there are 3 in 1 sets with the same bricks but multiple sets of instructions, and you can combine bricks from similar (or different) sets together for custom builds etc.

If we go back to site templates, some of these things apply in a similar way:

1. People may want to combine the blog feature from template x with the image gallery feature from template y - they can do that if those elements are also open source recipes in their own projects, although only when project browser supports it.

2. A fully built site template still needs to be hosted somewhere - someone who has paid $100 or $1000 for a site template will expect a friction-free hosting experience for it - if they can't run it easily on shared hosting, they'll be asking for refunds very quickly.

A site template without some of these things can work as a demonstration (similar to Umami) - e.g. you can look at a complete site template with demo content, see how it was put together etc., but to actually use it to build a live site, the ability to add/remove smaller features via project browser and be able to host and maintain it are much more important.

Related to maintenance, I also don't see anything in the proposal about how people who download site templates will access security updates and bugfixes - does this mean the entire template can be download and updated via public packagist then?

@catch -- which of these concerns remain to discuss here after RFC: The architecture and philosophy of site templates ( https://www.drupal.org/project/drupal_cms/issues/3534752 🌱 RFC: The architecture and philosophy of site templates Active )?

@farris all of the concerns regarding recipe browsing and project browser are unaffected by 🌱 RFC: The architecture and philosophy of site templates Active - it neither makes them less nor more of an issue.