Mass Market Archetype
Characteristics: Mass Market projects are often similar to “Wide Open” projects, but they necessarily have a protective layer around their contribution intake process. This is because there are simply too many users and too many opinions for everyone to be heard by the development team, and because the average technical sophistication of the users is low (especially in terms of their familiarity with the conventions of open source participation). This is especially true in a commercial context where product experience and time-to-market are highly sensitive.
Like B2B, Mass Market tends to drive down the price of directly competitive products, the way OpenOffice.org (and later LibreOffice) did with Microsoft Office. But Mass Market is less likely than B2B to affect complementary products, because Mass Market is usually aimed at individuals not at intermediary organizations.
Mass Market open source projects have certain opportunities that come with economies of scale, and they should actively seek to take advantage of those opportunities. For example, they can often get good translation (i.e., localization) coverage, because there are many users who are qualified and motivated to perform translation even though they might not have the skills to participate as programmers. Mass Market projects can do effective A/B testing and user surveys, and have some ability to influence de facto or formal Internet and Web standards. Finally, they can be thought leaders in a broader political sense (e.g., through industry partnerships, user clubs, etc).
Mass Market might at first seem more like a description of an end product than of a project archetype, but in fact there are important ways in which being Mass Market has implications for how the project is run. With developer-oriented software, it usually pays to listen to the most vocal customers. But Mass Market projects are oriented mainly toward nontechnical users, and thus should be guided more by explicit user research.
Examples: Firefox, LibreOffice, MediaWiki (due to Wikipedia instance)
Licensing: Non-copyleft generally, but may be copyleft depending on the project’s business strategy.
Community standards: Fully open, but relatively brusque for the vast majority of users. Because of the large number of users, these projects evolve toward a users-helpingusers pattern, rather than the development team serving as user support. The team itself can often seem somewhat distant or unresponsive.
Component coupling: Mix and match packages. This archetype can support a number of different component packaging techniques.
Main benefits: Large user base can help the project be broadly influential.
Typical governance: Technical committee and/or formal committer group.
@jcanovasi @evanleibovitch @quaid Please add feedback in comments.