Decide a name for user-focused distributions/products

-1 to "applications" -- these things aren't applications in the technical sense, nor are they applications in non-geek speak. That makes no sense at all as an option to me. Plus, there's all kinds of opportunity with confusion about a "Drupal App store", and the various efforts going into making "Drupal Apps", etc. In the not-too-distant future, these "distro thingies" might be collections of "Drupal apps", so let's not call the collection "apps", too.

-1 to "packages" -- lots of drupal things come in packages. Modules, themes, core, etc, are all "packaged". This is asking for further confusion and insanity.

+0 to "edition" -- seems wonky, and has no real meaning, but at least it's not actively bad.

+0.5 to "product" -- that seems closest in a number of ways. Unfortunately, it's both too general (a "product" can be anything produced by labor) and too specific (can conjure up thoughts of purchasing and retail), but that might be the least bad of the options.

+0.5 to "distribution" -- that's what we call them already, many people seem to understand, and we can certainly clarify with pithy phrases sprinkled around the relevant landing pages. I don't think this is as confusing and horrible an option as people make it out to be.

If I had an alternative I was excited about, I'd propose it, but it's late and nothing immediately springs to mind. If I think of something, I'll add it to the mix.

Probably we should accept synonyms, so that people can freely use distributions = distros = products = solutions to refer to the same thing, like in fact they are doing now.

However, naturally we should also select a main name to be used on drupal.org.

There is an interesting naming change proposal by webchick in another issue. It has distribution as a package-related name in the technical side for both packaged install profiles and distros (to reserve installation profile just for the scripts). And another name like product or similar (to be determined in this issue) to differentiate those of them that will be promoted in the end-user side (called distributions until now).

I'd say dww hits it - no name is going to satisfy everyone, and while a good name is important, clarifying our terms is also important.

I see more confusion for end users coming from the fact that we use install profile to mean two separate (but related) things - the script that runs once when drupal is installed (ie, a process) and as a way to describe a developer-focused distribution (ie, a downloadable thing). I'd like to see us move toward using these terms as follows:

* Install profile - the script that runs once when Drupal is installed
* Distributions/products - a useful thing that can be downloaded and installed. Distributions/products can have an end user or a developer focus.

RE "editions" we're not selling magazines, and the last thing we want to do is bring up images of the print world. Things aren't going so well there.

my vote is for 'distribution'. i've recently noticed a lot more people than I ever thought possible seem familiar with the concept due to their familiarity with ubuntu and other linux distros. Also seems to make sense as a cognitive analogy imo.

What about "Bundles"? That's what they are, essentially, yes? You can do Drupal a la carte, you can do a profile (which needs a new name, but "distribution" is no clear imho), or you can get a "bundle" which is a bundle of Drupal core and specific versions of modules that are tested to work together.

I would also like to see more leveraging of Drush-make-like function in profiles to dynamically pull in modules needed for profiles, because that's the middle site-building use case that can fill a real need not currently met. Right now you have a la carte building, current "distributions" which often run insecure, outdated modules, or for intermediate site-builders a ton of clicking and downloading to even run a profile, or for experts a custom personal/in-house solution. Yes, this is a tangential thought, but since we're talking about branding, we should discuss where the various components are headed, or we'll be back trying to rebrand again in a year, and that's just going to add to even more confusion.

@webchick: If we want to universally adopt the term "distribution" for "an install profile + .make file resulting in a fully packaged thing", that's great with me. That's the terminology what we've been trying to use ever since Fully packaged Drupal distributions now deployed on drupal.org. ;) One minor problem (a topic for a different issue) is that we never taught Solr and the Download and Extend section of d.o about install profiles that have .make files and are fully packaged, so there's no way to filter by those, etc. But otherwise, I've always tried to maintain that "install profile" is the .profile and .info file that's read by Drupal core, and a "distribution" is one of those that's been packaged with core and its dependencies from contrib.

SO, in that case, you're asking "what should we call polished distros?" (as per the title of this issue). ;) However, that should be more clearly reflected in the summary, I think, since the way the summary currently reads is confusing. If we're agreeing that "distribution" just means "install profile, core + contrib", we can't also call "polished distros" just "distros". So, it seems we have to remove "distro" from the list of possible alternatives here.

@laura s: I'm -1 on bundle because seems like a synonym for what we're calling "distribution". A "bundle" of code and configuration to get something done. That's as true of drupalorg_testing as it is of OpenAtrium. For that matter, Features could be thought of as "bundles of code and configuration". Nothing about "bundle" implies it's more polished or end-user-friendly than any other distribution. Basically, "bundle" is another way of saying "package" and I think we all agree that's not a good choice here.

Also, in terms of your requests about "drush-make-like" functionality, you realize we've already got that, right? ;) See the announcement I linked above. Meanwhile, I'm actively working on fixing a number of remaining limitations in that functionality so that hopefully all the major distros can move back to d.o over at the Install profile packaging community initiatives page.

Back to the terminology debate at hand: seems like the only viable candidates at this point are "product" and "edition". I share some of bonobo's concerns about "edition" although I don't think that word implies hard-copy print - anything that's published could have "editions". Regardless, I still think it's wonky and worse than "product".

I just looked through http://thesaurus.com/browse/product and some related entries and I found nothing worth seriously considering. The only things that even remotely caught my attention were:
- artifact
- blend ;)

Stepping back: if the point here is some way to distinguish end-user-site-builder-friendly distros from everything else, instead of a new top-level noun (for which I think "product" is the best choice at this point), maybe we just need an adjective to attach to "distribution". The landing pages, tab names, etc, etc will still all say "Distribution" but we'll sort (or perhaps filter) by the ones that are "polished". In that case, perhaps "premium distro"? For that matter, maybe "polished" is the most self-documenting. ;)

Works as designed? Should we go forth and fix the current install profile vs. distro confusion, and then just call the blessed/featured/polished distros "polished distributions"?

I don't want to unilaterally update the summary with my biased perspective on this, but I hope if folks agree we either quickly call this closed or update the summary with some of this.

Thanks,
-Derek

How about something such as "Quick Start" or "Easy Installation" or "Instant Website"?

The "install" in "Easy Installation" could be seen as a reference to the fact that an "Easy Installation" is a type of install profile -- specifically, an install profile that is deemed easy to use.

The problem with all of the terms currently proposed -- application, distributions, editions, packages and products -- is that none of them inherently conveys a message of "quick and easy," which I think is the message you're trying to deliver. All of those terms have roots in the world of computer geekery, which is not the best place to go if you want to find language that communicates to people who are looking for simplicity and ease of use.

It might be a good idea to get advice from someone with specific expertise in branding, advertising and marketing.

it'd be nice if we could brainstorm a bit first and see.

Coincidentally, I had tried the same search as dww, with the same result:

I just looked through http://thesaurus.com/browse/product and some related entries and I found nothing worth seriously considering.

Yes, a lot of funny synonyms of Drupal products there, such as Drupal handiworks, Drupal decoctions, Drupal fabrications... ;) Nothing useful, unluckily.

About the brainstorming until now, there does not seem to be much support for applications, packages, or bundles. Editions sounds ok for something official like a possible Drupal Standard Edition, but not so much for all distros/products.

So, in the case that we agree with webchick's recent proposal, and the name distribution is reserved for the technical side, then we have to consider just a name for the end-user side.

Below there are some suggestions mentioned so far.

Well, this is for the user side. Let's focus on the user ("... and all else will follow", as Google says).

Think for a moment... You are a new user who wants to try Drupal for the first time, to quickly install a site for a specific need. What would you like to find at drupal.org? To what section would you like to go?:

• Polished distributions
• Premium distros
• Products
• Solutions
• Top distros
• ...

And with which tagline?:

• Choose your Drupal
• Complete solutions for specialized use cases
• Drupal out-of-the-box
• Drupal made easy
• Drupal ready to use
• Easy installation
• Full-featured Drupal sites
• Instant website
• Quick and easy
• Quick start
• Specialized Drupal
• Specialized Drupal sites out-of-the-box
• ...

+1 for using distribution as the main terminology, as that is the most well known term currently used and is the same term is used for other software projects like Linux. Solutions is on the right track, but sounds more like it would be better suited as a handbook page or something.

I also like Top distributions or Top distros, as it implies that they are the best distributions and that only. Using polished means everyone needs to understand what a polished distribution is (more confusion) and Premium could imply that payment is required. Think of Premium Drupal themes and you see the problem.

Drupal Quick Start sounds like where you want to get started if you are a Drupal n00b, or we go with the Drupal Commerce terminology and have a Kickstart :) In any case, I like where this discussion is going!

techsoldaten just posted a great comment at #1314124-36: [META] Improve installation profile listing on Drupal.org which I think is helpful when thinking through this problem.

I think in most places we should just call them "distributions". In places that are sorted by popularity/shine, +1 to "Top distributions", however, I strongly agree that the main thing is that these are pre-packaged solutions for specific use-cases and that end-users will care much more about finding a distro built for their target audience than the one(s) with the most polish.

Therefore, +1 to "Complete solutions for specialized use cases" as the tagline (at least out of juan_g's nice list). It's a bit long, and slightly in the direction of more technical, but I think it's by far the most useful and self-documenting phrase to describe these for people trying to find the right thing to download.

In any case, I like where this discussion is going!

Me, too! In spite of the title of this issue, there's been no uninformed bikeshedding, just thoughtful comments trying to hash through a sticky naming problem. Yay.

webchick, sk33lz, and dww wrote:

Incidentally, my vote is still for "Drupal products."

I also like Top distributions or Top distros

In places that are sorted by popularity/shine, +1 to "Top distributions"

webchick wrote:

I think most geeks call them distributions, and most geeks trying to explain distributions to non-geeks call them products. :D

Then, should the top distros be called products, or should the products be called top distros...? Or both?

For example, maybe something like:

Drupal Products

The top Drupal distributions, complete solutions for specialized use cases

Other opinions?

Yes, since the slow weekend is just starting, let's have at least some more days so that other people can express their views.

For now, this is a summary of what the community has said so far.

In any case, I like where this discussion is going!

I also like how so many different proposals from the community are coming together now, like pieces of what seemed a puzzle. A lot of people are contributing their ideas here and in a number of related issues (see the links on this post).

For example, we don't yet know whether users will see products, or top distributions, or both, but the general structure seems to be being accepted. It has been proposed by webchick, after experimenting with the previous proposal, that was:

• Installation profiles, the scripts
• Installation profiles, the packages (time-saving tools for development and site building)
• Distributions (very elaborated, full-featured products for site builders and end-users)

It has become now, with provisional names like kickstarters that are being used in these issues, to explain the new general structure:

• Installation profiles (just the scripts)
• Distributions (the packages, for development and for users):
  • Kickstarters, or the dev distributions (dev distros)
  • Products, or the top distributions (top distros)

That is, webchick has proposed to use the name installation profiles just for the scripts, as suggested by bonobo, calling distributions -at least in the technical side- to all downloadable packages (core + install scripts + possible modules, themes, configurations, libraries, etc.) called before installation profiles and distributions. This has been supported for example by dww, from the drupal.org's infrastructure team. Also, cweagans proposed just a flag, instead of a new project type, to distinguish user-focused distributions from development profiles.

So, the products for users -or other name- will be a subset of distributions, in fact the top downloaded distributions. In this issue, webchick is asking for the name or names that will be seen in the landing page for this subset of distributions featured for users.

Specifically, since the word distributions is needing so many explanations for users, she asked for a different, clear word for end-users like for example products. Dww agreed that products is the best viable candidate for a different word, but suggested that a clarifying adjective for the word distributions could be enough to name the subset. Webchick also agreed on these two possible options: new word, or modifier.

Products is a word used by many in the community lately, such as people around the Snowman project, sun's proposal Choose your Drupal, and many more.

Top comes from sun's "Top most downloaded Drupal products" in Choose your Drupal, at the request of dww in this issue for a modifier of the word distributions.

And a possible tagline, "complete solutions for specialized use cases", pre-selected by dww, seems to be in the line of what he, webchick, and others like techsoldaten are saying. It comes from a more technical definition by bonobo, "a set of modules, themes, and specialized config designed as a nearly complete solution to a well-defined use case", but simplified to be easy to understand by users.

Surely I'm forgetting proposals and ideas from many people in all the related issues (follow the links for more details), but this can be a summary of what the community has been thinking and talking on this distributions/products topic.

As said, let's have more views from other people before selecting the best available solution.

Maybe the issue isn't labels but context? Tossing in another word, "products", doesn't address the real problem we have: We still have too much organization based on how we, the old hands, are comfortable with thinking about Drupal, and we're drawing on years and years of legacy thinking. What does the newbie to drupal.org think? What are her questions? What job is she trying to solve?

Some clarity and description are going to be needed for any newbie, whatever the label. Something like:

Distributions - download a pre-packaged flavor of Drupal, with pre-configured and configurable modules to serve particular needs. Browse the distributions available (link).

Installation Profiles - Start building your site with automated website and web app recipes that can give you a big head start on your project.

Phrases like "polished distributions" I feel are misleading, and could be a set up for many disgruntled site owners who don't appreciate how buggy modules and insecure releases can be in "polished" packages.

And "products" I feel sets people up for misunderstanding that you don't download Drupal, you adopt Drupal, you obtain a process, not just code, and that Drupal as as much a vibrant (open source) community as as it is a tarball of code.

Phrases like "polished distributions" (...) how buggy

@laura s: Other possible adjective could be "full-featured", that is sometimes used to describe user-focused distributions.

What does the newbie to drupal.org think? What are her questions? What job is she trying to solve? Some clarity and description are going to be needed for any newbie, whatever the label.

Yes, it's true that short descriptions in the UI would be really useful. Also categories by use case, etc.

In places that are sorted by popularity/shine, +1 to "Top distributions"

@dww: I'm thinking, "top" is excellent for the purpose you mention (featured or top downloaded lists). That means there could be different lists for both top user-focused and top development-focused distributions. For example, the performance distro Pressflow could be in a list of "Top development distributions", or equivalent.

So, "top" is good for those lists in the user interface as you say, but less useful to strictly name the subset of user-focused distros. And we can't ask in the project forms "Is your project a top distribution?". Because of this, when I've exchanged with dww a few ideas about the project form (he prefers a field rather than a flag), "full-featured" has been suggested instead.

That is, some possibilities are:

• Installation profiles (just the scripts)
• Distributions (the packages, for development and for users):
  • Tools, or quick-start distributions, or development distributions, or quick-start development tools
  • Products, or full-featured distributions, or user-focused distributions, or full-featured products for users

With top for the sections/lists of most popular/downloaded.

To simplify, the issue title asks:

What should we call "polished distributions"?

Well, it's just a name, but we don't have one yet. As webchick has said:

it'd be nice if we could brainstorm a bit first and see.

So, as related derivatives from the community discussions in these issues, possible brainstorming ideas for the subset of user-focused distributions are:

#1. User Distributions.
#2. Full Distributions.
#3. Full-featured Distributions.
#4. Complete Distributions.
#5. All-inclusive Distributions.
#5½. Whole/Comprehensive/Integral/Rounded/Thorough/Fulfilled/Full-blown/All-the-way/All-out Distributions. Brain explodes... Sunday, sorry. ;)
#6. Solutions.
#7. Or simply, Products.

Other opinions?

webchick wrote:

"Full-featured distributions" is now my new favourite

Then, if people agree and we use distributions as the main name, with subsets like full-featured and development, maybe we can use also products in the descriptions. The use of both distribution and product seems to be having favorable acceptance at least in the descriptions of the project form for distribution maintainers, from other related issue:

How would you describe this distribution?
(*) A quick-start tool for developers and site builders
( ) A full-featured product for site builders and end users

So, this seems suitable for the maintainer side, just a little bit technical so that the difference between the two subsets of distributions is clear to understand.

Those short descriptions could be adapted to obtain appropriate descriptions for the user side, possibly using the tagline pre-selected by dww, "complete solutions for specialized use cases".

This would mean that people could use synonyms for the two subsets of distributions, for example:

Development distributions = dev distros = tools
Full-featured distributions = full distros = products

And, in the landing pages for distributions, titles and taglines for users (in addition to other longer, needed descriptions) could be similar to:

Development distributions

Quick-start tools for developers and site builders

Full-featured distributions

All-inclusive products, complete solutions for specialized use cases

So, what do people think?

Hm, I think you are right. Maybe it could cause confusion with what is sometimes called development profile.

That suggestion for non full-featured distributions, "development distributions", used development in a general sense (code and/or site development), just to distinguish them from full-featured, already developed sites. But of course this was just a possible idea.

Other similar possibilities we can think of, in the case that for example a section, tab or sub-tab is included for those non full-featured distributions:

• Site building distributions, or:
• Quick-start distributions, or:
• Other distributions

For example, some popular distributions for site builders like for instance Pressflow (performance), or Acquia Drupal (generic) seem likely candidates for lists of "Top site building distributions" or similar.

And development profiles like media_dev, etc. also involve quick site building, in addition to code development. So, that name "Site building distributions" could be suitable for all non full-featured distributions. Probably there is no need to have three subsets of distributions for development, site building, and full-featured, but it's of course another possibility.

webchick wrote:

I would just call "Development" distributions "Distributions", and make the distinction between full-featured ones and regular one.

Thinking carefully, this also seems a good idea, to prevent any possible complication about special distributions. I think dww suggested something similar as well.

In that case, a possible sub-tab would just say "Other distributions" or something like this. Therefore, the previous names for the distribution subsets, with possible taglines, would become:

Full-featured distributions

All-inclusive products, complete solutions for specialized use cases

Other distributions

Quick-start tools for developers and site builders

With synonyms that people could use like:

Full-featured distributions = full distros = products
Other distributions = other distros = tools

And that's it, full distros and other. Looks all right to me, at least as a starting point. Let's see what people think...

I like where this is going. General +1 to #23 and #25.

One quick note about #22. This caught my eye:

... pre-selected by dww

Sure, I'm on the infra team, but that doesn't mean anything I write in an issue is automatically "pre-selected" as if it's certain to happen that way in the end. I'm wrong a lot of the time, too, just like everyone else... ;)

Thanks,
-Derek

+1 to juan_g's proposal/summary in #25.

It's simple, and provides a great starting point.

Open Atrium, Voicebox, COD, Commons, Portfolio. What's the name for those things, that differentiates them from Drupal.org testing profile, Media dev profile, etc. so that they're not shown next to each other in the same list for the same target audience?

This question excellently clarifies that this entire issue started with a completely bogus question.

Let me extract the actual question out of that for you:

What's the name of the thing that differentiates them so that they're not shown next to each other in the same list for the same target audience?

The thing is called "taxonomy" and it allows to categorize projects into use-cases and target audiences.

If you are a new, inexperienced user, and you want something suitable (sorry, "polished") for beginners, then it would naturally be a bad idea to try a profile intended for developers. Wouldn't it?

So how do we prevent those profiles from showing up next to others?

Simple. Like we always did: Filter by taxonomy, by target audience.

I would just call "Development" distributions "Distributions", and make the distinction between full-featured ones and regular one.

Thinking carefully, this also seems a good idea, to prevent any possible complication about special distributions.

You realize that one needs to read up plenty of comments on several issues in order to make any sense of this and understand where this distinction and complexity is coming from?

Full-featured distributions
All-inclusive products, complete solutions for specialized use cases
Other distributions
Quick-start tools for developers and site builders

So suddenly we're saying that site builders shouldn't use "full-featured distributions"?

And what about "full-featured" profiles that are still also meant as tools for developers and site-builders?

- Installation profiles (just the scripts)
- Distributions (the packages)

That's technical hairsplitting to describe the content of an archive. It's relatively pointless to make that differentiation, since no one aside from profile developers actually needs to deal with or care for the pure "script" components.

The outcome is a download package that contains the profile and the parts needed to install the profile.

Product

is the outcome of designing, developing, and bundling the appropriate solutions for use-case specific problems into a good.

There is no commercial aspect to products, unless you add one.

I'm not building a distribution. Totally not.

I'm building something to solve a problem. I'm building a product.

Here's a (devil's advocate) question: If we look at all this from the d.o visitor trying to figure this out, are these distinctions going to make any sense at all? What is the d.o visitor looking for? What questions does she have?

* What does this distribution do? Will it do what I need? I'm building a foobar site - will it do that?
* How hard is it to install and get going?
* How hard is it going to be for me to customize it into what I want? Do I need to know CSS?
* Will themes on Drupal.org work on this distribution?
* Will modules on Drupal.org work on this distribution?
* How much will I need to use the command line? Can I use FTP?
* Will it be secure?

These are just surface questions, and we all know how each can drill down into all kinds of details to the point where every answer could be "It depends." (Most of these folks would not even know to wonder about hacked modules.) Many of these questions could and should get answered on the individual project pages, obviously.

I am not raising these questions as topics that should be answered in the proposals in this issue and related issue #1314124: [META] Improve installation profile listing on Drupal.org, but I do ask how the people asking these questions on this level, who are likely very unfamiliar with Drupal, are helped by renaming "Distributions" and "Profiles" with shiny new handles. Putting on my n00b hat, "products" is pretty vague. A saw is a product. So is a bookcase. How does calling them products help?

"Full-featured distributions" also brings confusion to me. Full-featured in what sense? Does that mean it does what I need? Or does it mean that it does what it does, period, and I had better not try to modify it any? The phrase is loaded with hidden meanings.

"Other distributions" means, I guess, what doesn't fit in the other (vague) category. Does this mean if I use an "other distribution" it won't do what I want it to do and it won't work unless I do programming/coding? Or does it mean that it's a distribution that I can extend and customize easily?

The thing is called "taxonomy" and it allows to categorize projects into use-cases and target audiences.

If you are a new, inexperienced user, and you want something suitable (sorry, "polished") for beginners, then it would naturally be a bad idea to try a profile intended for developers. Wouldn't it?

So how do we prevent those profiles from showing up next to others?

Simple. Like we always did: Filter by taxonomy, by target audience.

I beg to differ. Taxonomy maybe simple to implement, but it's not necessarily simple to architect for a smooth and effective UX for the Drupal.org user. From my comment on #1314124: [META] Improve installation profile listing on Drupal.org:

What does "skill level" mean? Skill in what? Systems administration? PHP? Where to find the double-secret buried Drupal configuration settings? Skill level required for installation? Skill needed for site maintenance? Skill needed for additional customization?

For example, Open Atrium is pretty darned simple now to install and bumble through configuration, but you'd better want what OA gives you out of the box because customization requires not just Drupal expertise but real comfort with Features and perhaps some "hotsauce" knowledge. So what skill level rating should OA get?

Taxonomy can be very effective, but I feel it requires a lot of exploration and, ideally, user testing.

Putting on my n00b hat, "products" is pretty vague. A saw is a product. So is a bookcase. How does calling them products help? "Full-featured distributions" also brings confusion to me. (...)

@laura s: It's true that any name for this subset of user-focused distros is not going to be completely clear for users. Even if we call them simply "distributions for users" or other name, people will ask what does that exactly mean.

Since there is not a perfect name, that's why short taglines and also longer descriptions are needed in the UI, in addition to a more or less clear name. For example, a recently RTBC proposal on this issue (#25) combined the words "distributions" and "products" in names and taglines, using products as a synonym of full-featured distributions, to provide a clearer general meaning for users:

Full-featured distributions

All-inclusive products, complete solutions for specialized use cases

Other distributions

Quick-start tools for developers and site builders

The rest of details would go in longer descriptions, lists by specific use cases, documentation, project pages, etc.

Some prefer the word "products" in the name, as clearer for new users. In that alternative case, for more complete clarity, the well-known name for current users "distributions" should also be included in taglines and descriptions, in a similar way to the other possible, inverse solution.

About taxonomy, the two main groups that we can see in the current reality of distributions, that is those ready for users (or rather for users and builders), and the rest (for builders and developers), seemed enough for the purpose of landing pages, etc., and was just following the practical, current facts on distributions.

Anyway, also a more specific target-user taxonomy with three or more options (user, builder, developer...) could also be used for this. However, theory and reality are different, and the fact is that most of the current distributions would need a multiple selection, two tags. But it's indeed also an alternative possibility.

About skill level, if there are three target user tags or the initial two subsets solution, in my opinion skill level is probably not necessary, at least for now.

And I think all agree about using taxonomy at least for use cases. See for example #1360660: Should we use the Sector vocab for classifying distributions? What additions do we need?, and e) in the current proposal, comment #34 of the meta-issue.

I wonder whether the ongoing "full-featured distributions" suggestion and confusion actually tries to describe something different but very concrete:

Do you mean Products based on Drupal, which you can install and use as-is, but you're not supposed to change them?

I've heard a couple of rumors about Open Atrium and similar products saying that people have a very hard time to customize and tailor them to their needs, and in the end, that is (or might) also not be the (vendor's) intention. Instead, the intention is to deliver a product that's ready for roll-out, but, which is not supposed to be customized further than the product itself allows for (for various reasons, one of them being maintenance updates/upgrades sorta requiring a defined, expected, and reliable set of components and configuration).

If that is the idea, then I could see a point in explicitly flagging these projects/products. That is, because it essentially means that the product you're downloading is factually not like Drupal. You cannot change it, extend it, or customize it -- or if you do, then you're on your own. In fact, you get and use a theoretically locked-down Drupal.

At least, that would be a clear difference to other, "full-featured" product projects - such as Portfolio - since their goal is to deliver a ready-to-rumble site for a specific use-case, but still allow for full customizations (just like Drupal core).

The difference is, however, not in volume of features, nor in quality, and also not in "polished." The difference is in "locked-down."

Again, I'm not sure whether that is the idea - but if it is, then

1. I'd have a huge problem with exposing those products/projects in a special and prominent way on drupal.org - as in "full-featured yadayada", and kinda suggesting them over regular profiles/products/projects.

   (Because that would be a pure marketing purpose, and so a simple list of links to their dedicated web sites would be way more appropriate.)

2. I'd bluntly name and call them what they are: "(Third-party) products based on Drupal" (the important part is "based on")
3. In the end, it still boils down to a taxonomy term or facet that not only allows to filter the list accordingly, but also add a warning to the project pages, so users don't mistakenly believe that they can hack and shred their site as usual.

Each distro is different, and some are easier to customize and extend than others. However, they currently tend more and more to at least have many optional features that can be enabled/disabled.

For example, an interesting publishing distro with additional extendability possibilities is the NodeStream 2 distribution platform. See as well An alternative way of structuring features for distributions.

Also, Open Atrium can be customized by developers and site builders, but also has contributed features available on distributed feature servers, in a similar way to modules.

@sun wrote:

If that is the idea, then I could see a point in explicitly flagging these projects/products. That is, because it essentially means that the product you're downloading is factually not like Drupal. You cannot change it, extend it, or customize it -- or if you do, then you're on your own. In fact, you get and use a theoretically locked-down Drupal.

This is an important point and goes to the heart of a problem with equating "polished" with "easy to build with." As a general rule, distros tend to be easier to install initially than the experience of building that same functionality from scratch starting from Drupal core, but they achieve that ease of initial installation at a price of being harder to customize and upgrade. I've seen this pattern with Open Atrium, with OpenPublish (which I like a lot), with OpenPublic (which I like less), and with others.

A distro is built on an installation profile that typically includes not just a number of contrib modules, but specific releases of each of those contrib modules. It is not uncommon for the distro to also include patches to some of those contrib modules. The result is that when you install a distro, you are installing a collection of Drupal contrib modules that are frozen at the specific moment in time when that distro was packaged for distribution. I experienced this when I did some work with the first beta release of OpenPublic. It contained older versions of the Views, Calendar and Date modules for D7, and there were problems getting those particular versions to play well with the client's particular needs. My options were therefore to upgrade to the latest dev versions of each of those modules or to say no to some client requests for functionality. If I upgraded to the latest version of those modules, I did so at the risk that there might be problems down the road when it came time for the client to update to a newer release of OpenPublic.

With OpenPublish, I ran into an issue in which the installation profile used a patched version of the latest dev version of a module which included a database schema change that differed from the schema change that ended up in the module's next actual official release. This produced a bug when I tried updating that module which a Drupal novice would have had trouble diagnosing and fixing. So here's the paradox: OpenPublish is in opinion one of the most polished and usable Drupal distros. You can set up a pretty nice online newspaper in just a few hours with it, and it has lots of well-implemented features to make a client happy. However, upgrading or modifying OpenPublish can actually be harder to work with in some ways than if you built a website from scratch. If you're rating it by required developer skill level, therefore, in some ways it is easy for beginners, and in other ways it requires a high level of expertise.

I talked with some of the developers at Phase 2 awhile ago, and they told me that with their installation profiles, they advise against modifying or updating any of the contrib modules that are included in the /profiles directory. They consider this advice "the distro equivalent of not hacking core." If someone does need to change anything in the /profiles directory, they recommended at a minimum documenting the changes carefully and creating patchfiles so that the changes can be reapplied when updating the distro later to a newer version. These sorts of requirements make distros generally more brittle than custom-built solutions. And I'm fairly certain that there are people building websites now with distros who aren't fully aware of these recommendations and aren't following them, which means they are painting themselves into a corner and will have upgrade problems in the future.

Thanks for the clarification, @Sheldon Rampton.

So to me it sounds like we finally reached the root cause and issue. And with all the nice real-world examples of trouble in #34, such as patches and schema hacks in bundled modules of those profiles, yes, it factually means that you have to be a very advanced Drupal developer in order to update modules or install new ones. As a novice developer, regular site builder, and even more so as a user, you're essentially locked down to the modules and features the distro provides. It is way more clear to me why you guys are actually started to talk about "distributions" now.

As a first measure, I'm trying to improve the issue title to clarify the topic. We also have to clarify/rewrite the issue summary, because all of this talk about "polished" means nothing and the world to others.

Lastly:

While I can see the technical benefit of allowing profiles to move forward while waiting for so called upstream fixes/improvements in bundled modules, this possibility is actually not something I'd like to officially endorse and encourage for installation profiles. And I'm fairly sure the rest of the community doesn't want that either.

From my perspective, this technical possibility is not a feature - it is a bug. It totally maps to the "Don't hack core" principle, just on a different level. In an ideal world, code customizations and hacks would not be necessary, but I can very well see that the reality looks different at times.

In the end, I still wouldn't make a difference between regular installation profiles and those containing hacks. I wouldn't call them distributions either. All I'd do and recommend is to spit out a bold warning text for those profiles, which explains to users who are shopping for a product/profile that you very likely cannot customize the resulting site in the usual ways.

I'm not sure whether such a warning would need a manual checkbox or flag for installation profile projects, or whether it couldn't be automated by the fact that an installation profile's build script contains references to patches to be applied to the bundled code.

That's another issue that could be opened. A correct title for the current issue would be the initial one, or for example "Decide a name for user-focused distributions/products". That is, a name for distributions suitable for users, like the recent RTBC, or products, etc.

What you mention is a completely different and complex topic that should be researched case by case, distro by distro. Each distribution has of course its own specific advantages and disadvantages. Sincerely, it's wrong to generalize in that way.

It's normal to see different kinds of problems in first versions, that are fixed in second versions because users ask for a fix. Just like in contributed modules or in core.

For example, people complained about the first version of Commons being difficult to customize. I was also interested about that, and noticed the cause: everything was mixed in one monolithic feature. So, I opened the issue #892496: Split the Commons Core feature into single features, and it was fixed with 14 optional split-up features as a start.

Did you read the links in comment #33?: Especially An alternative way of structuring features for distributions, etc. I think that's important to have a real and balanced view.

It's really a different issue. Please open one if you think that a meta-issue for different issues needing a research distro by distro is necessary.

For example, "Measure how customizable, extendable, and upgradable each distribution is in the current versions".

I feel @sun in #32 and #35 and @Sheldon Rampdon in #34 get at the heart of the problem here, which is that the proposal(s) in this issue don't really clarify or properly contextualize the natures of these various distributions. "Full-featured" vs. "other" does nothing but highlight a few select distributions for highlighting and toss the rest into the remainders pile.

What is the purpose of this distinction? To add more showcasing opportunity for the keep-the-hood-bolted-shut distributions? Is the other pile the "we don't know what to make of these distributions" pile?

How do these arbitrary labels provide any info for the person trying to figure out how they are going to build the site they have in mind? "Full-featured" is as ambiguous and open to interpretation as "polished". How "full-featured" a distribution might be deemed truly depends upon what the person is wanting to do. Plain Drupal core is full-featured for simple needs.

What problem is this issue attempting to solve? Can we go back to that? For example, were now at "Decide a name for user-focused distributions/products". What are "user-focused distributions/products"? What would "non-user-focused" distributions be then? We've gone back and forth on what "user" means, and it's still this vague concept. Can we focus on addressing what that nebulous "user" needs as opposed to what "we" want to pitch?

Are they trying to solve actual problem/use cases or are they simply a development/quickstart tool? The ones in the latter do not help target audiences of the former in the least,

This is an assumption that people who might be interested in, say, OpenPublish come to Drupal.org asking, "I wonder what kind of website I can set up easily?" and see OpenPublish and say, "Hey I can launch a magazine!" I am not convinced that this is the case. Don't people have something in mind and they're looking for solutions for that? I sincerely believe only a minority would browse solutions and try to think up ways they can use them, and that most people are would be looking at distributions/profiles in terms of how well they fit their pre-existing desires/needs/requirements. Maybe I'm mistaken in this?

Don't get me wrong, I am 100% big über-mega +1 on making more sense of all this for Drupal.org visitors. I am pushing for focus on what these people want and need, what questions they're asking, and let those things drive how we think about categorizing, labeling and highlighting what's here.

RE:

Don't people have something in mind and they're looking for solutions for that? I sincerely believe only a minority would browse solutions and try to think up ways they can use them, and that most people are would be looking at distributions/profiles in terms of how well they fit their pre-existing desires/needs/requirements.

I don't think it's necessarily an either/or. How many times have we talked with people who had, at best, a general idea of how they wanted their site to work? Or, better yet, how many times have we talked to people who *thought* they knew *exactly* how they wanted their site to work, but upon additional discovery/thought realized things that they had missed/overlooked?

These are also people coming to d.o looking for solutions. Seeing some possibilities can help awaken imaginations to some of the options out there.

I think part of the complication here is that ANY distribution, no matter how "polished" or "feature complete" will need some customization to work for the use case required by the end user. Because of this, a fully accurate, universally useful system of categorization is beyond our reach now. However, a lightweight structure, paired with better description, paired with some minor design changes, can improve the experience with finding and discovering distributions.

Perfect? No way. Better than what we have now? Certainly.

And, more importantly, the feedback we get from this will help drive the next version of this. The work around distributions on d.o should continue on past what we do now; how we talk about distributions will continue to grow and shift as the available distributions continue to grow and shift.

With all due respect to webchick, I don't think the problem posed at #1205640: Figure out some means of separating "Drupal Products" from "Install profiles" is simply "everything to do with the focus of those distros. Are they trying to solve actual problem/use cases or are they simply a development/quickstart tool?" Moreover, webchick's standard as stated here depends upon a subjective assessment of the intentions of the person who created the install profile or of the people who might download it. In practice, I don't think that assessment is always clear-cut. (For example, is Commerce Kickstart "trying to solve an actual use case" or is it a "quickstart tool"?)

From the beginning, the problem was described as involving the identification of "polished 'products' with Drupal under the hood" in which "a lot of the rough edges are smoothed over, and lots of care is given to user experience. ... Because for people for whom Drupal is too hard, distributions is a lot of times what they need." Clearly, this way of stating the problem does attempt to distinguish between projects that are easy to use from those that are not, and posing the problem in that way does in fact require recognizing that some distros are "more equal polished than others." (Karen Borchert's proposal for improving the display of distributions on Drupal also advocates a "merit-based system for displaying distributions.")

I've spent a bit of time reviewing some of the several tickets that discuss Drupal installation profiles and distributions. It appears that basic concepts and terminology are still in flux, despite repeated efforts to clarify them. You can find people therefore claiming that the relationship between "installation profiltes" and "distributions" is any of the following:

• Installation profiles and distributions are "not remotely the same"
• "Installation profiles and distributions are one and the same thing they do not differ neither technically nor by intent.
• an installation profile is a type of distribution
• a distribution is a type of installation profile
• all installation profiles are distributions, but there is a separate type of "distributions intended for users."
• distributions can include "Drupal core," "Full-featured distributions," "Other distributions" and "SaaS offerings."
• An installation profile is "a recipe" whereas a distribution is "a code restaurant. ... [A]ll distributions are installation profiles, but not all installation profiles are distributions."
• distributions = distros = products = solutions. These are all synonyms that refer to the same thing.
• installation profiles are for site builder, and distributions are for end users.
• distributions are more "polished" or "easy to use/install" than installation profiles

"Installation profile" and "distribution" are of course not the only terms being used here. I think I could also find examples of people arguing that products and distributions are synonymous, that products and distributions are different, that one is a subset of the other, etc.

As a precondition for effectively setting policy for how Drupal.org should categorize and display these things, some clear definition of concepts is necessary. I don't know if my approach helps clarify or not, but for what it is worth, here are three basic concepts that I would define as follows:

1. An installation profile is a script that specifies a collection of modules and other code along with configuration settings needed to set up a specific type of Drupal-based website. The concept of "installation profile" is defined according to coding conventions that are as clear and specific as Drupal's conventions for defining modules, themes, hooks, etc. Installation profiles are not the only means available for specifying a specific type of Drupal-based website. (For example, there is the technique of release a tarball containing the site's code and a MySQL dump.) However, installation profiles are the recommended way of doing so and are the only method that Drupal officially supports, through a content type and section on Drupal.org similar to the sections which exist there for modules and themes.
2. A distribution is a publicly shared collection of files that can create a Drupal-based website consisting of a particular version of Drupal core along with possibly additional modules, themes, installation profiles and libraries, as well as configuration settings for those components. Since an installation profile defines a specific distribution, Drupal.org uses a packaging script that creates a downloadable tarball of each installation profile that it hosts. However, a distribution is not an installation profile and does not even need to contain an installation profile. Any packaged codebase that is based on Drupal is a distribution, regardless of the technique used to share or install it and regardless of whether it is hosted on drupal.org. Moreover, a distribution might include other characteristics that deviate from Drupal best practices, such as hacks to core. Calling something a distribution is not a recommendation or an endorsement or a statement about its quality, polish or usability. It is simply a definition of a collection of files that can create a Drupal-based website, as stated above.
3. A product is a distribution that meets quality standards sufficient to warrant being listed in a "highlighted distributions" page that may be referenced on the drupal.org home page. A product therefore does have to conform to some Drupal best practices and possibly meet some other quality standards as well, along the lines that Karen Borchert suggested:
   • Presence of Documentation
   • Presence of screen shots
   • Security / security team review
   • Actively supported by a professional team
   • etc.

I think these definitions are clear and unambiguously establish distinctions that can be used in a non-subjective fashion, although there may be some controversy over which distributions deserve to be listed as products.

I am closing this issue due to inactivity. The latest comment was 2 years ago. However, there is a great discussion happening so if you wish to open this issue again, please do. Thanks.