Open Community Development Models issueshttp://opensource.ieee.org/groups/community-advisory-group/open-comm-dev-models/-/issues2023-04-10T17:00:22Zhttp://opensource.ieee.org/community-advisory-group/open-comm-dev-models/resources/-/issues/1Clarifying license content of Maintainers Manual2023-04-10T17:00:22ZKarsten WadeClarifying license content of Maintainers ManualIn recent discussions in the OSCOM Ad Hoc Committee on Governance, we discussed several questions and concerns about this section of the Maintainers Manual:
https://opensource.ieee.org/oscom/maintain/-/blob/master/content/maintain.md#82...In recent discussions in the OSCOM Ad Hoc Committee on Governance, we discussed several questions and concerns about this section of the Maintainers Manual:
https://opensource.ieee.org/oscom/maintain/-/blob/master/content/maintain.md#82-licensing-and-control-of-contributions
Observations included:
1. Inclusion of a CLA as an option is confusing and probably inaccurate.
2. Open Source projects choose their licenses for complex reasons, and in many ways a license is a developer culture decision. Having a specific list of allowed licenses is a potential anti-pattern.
3. It would be common and reasonable to have a short list of recommended licenses, ideally to include a range of license flavors (copyleft, permissive, etc.) and versions within (ASL, MIT, and BSD for example).
4. Missing a Creative Commons license choice, which would apply to content-only projects.
Note: issue is temporarily in this issue queue until a different project can be setupKarsten WadeKarsten Wadehttp://opensource.ieee.org/community-advisory-group/open-comm-dev-models/about/-/issues/8Create summary of the four archetypes categories discussed2022-02-16T21:27:24ZBeth HancockCreate summary of the four archetypes categories discussed1. Business-to-business (B2B) Open Source – My opinion is that we won’t see many if any of these kind of projects. I don’t believe we will be the host for the next Android or Chromium project.
1. Multi-Vendor Infrastructure – Similar to ...1. Business-to-business (B2B) Open Source – My opinion is that we won’t see many if any of these kind of projects. I don’t believe we will be the host for the next Android or Chromium project.
1. Multi-Vendor Infrastructure – Similar to #1, I doubt SA Open will be chosen for this kind of project.
1. Rocket Ship to Mars – While I doubt any of our projects will be as aspirational as the name of this archetype suggests, we may have some ambitious efforts that may be standards related or come out of some other organization such as humanitarian activities.
1. Controlled Ecosystem – This may be similar to #1 and #2 and be less likely within SA Open.
1. Wide Open – I can imagine these kind of projects arising within IEEE. They would likely not be standards related but perhaps they could be.
1. Mass Market – Like #1, #2, and #4, these kind of projects probably won’t be common on SA Open.
1. Specialty Library – I can imagine a number of IEEE standards where a library of functions related to a standard would be applicable.
1. Trusted Vendor – I think this is more of a commercial activity like #1, #2, #4, and #6 and would be less common.
1. Upstream Dependency – I think this could be common when the dependency is a standard.
1. Bathwater – I could see a number of standards projects where someone writes reference or example code and then throws it over the wall.
Josh: Over all, I think we should focus on: 3, 5, 7, 9, and 10 first and then take a stab at the others
Evan suggested combining some of the above and addressing a limited number of them.
Josh: 3 and 5 can be combined, 7 and 9 can be combined and 10 would be separate.
After more discussion: Evan suggested also combining 1,2 and 4 as well for a total of 4 project categories.Josh Gayj.gay@ieee.orgJosh Gayj.gay@ieee.orghttp://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/10Bathwater Archetype2021-11-10T14:23:31ZBeth HancockBathwater Archetype**Characteristics:** This is code dumped over the wall. It is purely about distribution, not about
any particular mode of production. Think of it as the ground state of open source projects:
someone publishes code under a free license bu...**Characteristics:** This is code dumped over the wall. It is purely about distribution, not about
any particular mode of production. Think of it as the ground state of open source projects:
someone publishes code under a free license but invests no followup effort into building
open source dynamics.
Typically, the published code is not the organization’s prized technology. In some cases it is a
one-off publication and thus likely to become quickly outdated. In other cases, there may be
a public repository, but that repository is not where development occurs — instead it is just a
container for periodic snapshots of particular release points. Sometimes there is not even a
public repository, and the only thing published is a release tarball or a sequence of them.
Code gets dumped this way quite often, and “throwing code over the wall” has a bad
reputation among open source practitioners. Merely publishing code under an open source
license is unlikely to generate any of the beneficial effects that come from truly investing
in open source. When those benefits don’t materialize, developers sometimes take it as
evidence that open source “doesn’t work”.
Although experienced open source professionals look down on Bathwater projects, they do have
some uses. First, they work as an initial foray into open source. For inexperienced firms testing
the waters, there are few benefits from open sourcing this way but also few risks. They can claim
to be doing open source, send signals that they are open to more open source engagement, and
perhaps that positions them to do a more complete job the next time around.
Second, even for firms experienced in open source, Bathwater is a reasonable final state for an
abandoned initiative. When an organization is ready to stop devoting any resources to a project,
explicitly putting the code into Bathwater mode, and giving the world permission to take it up,
can be a final attempt to give the project a chance at impact and serve the existing user base.
Bathwater treats the code like a forkable resource. Users of Bathwater projects don’t expect
anything from upstream, because there is no upstream anymore, but they can can consider
their involvement as a greenfield opportunity. If they are willing to invest in the code, they
can choose any one of the other archetypes and start building toward it.
Although numerous, Bathwater code bases tend not to be famous, because they don’t get much usage unless they attract an open source maintenance community – at which point they transform into one of the other archetypes. One recognizable example of Bathwater code is [https://github.com/Conservatory/healthcare.gov-2013-10-01](https://github.com/Conservatory/healthcare.gov-2013-10-01) which was essentially a one-time dump of the front end web code for the original http://healthcare.gov site developed by the U.S. government. (Although technically in the public domain, that code could in principle have been adopted by anyone and the resulting fork placed under an open source license. As is often the case with Bathwater code, that uptake did not happen.
**Licensing:** Varies, sometimes missing, often incoherent.
**Community standards:** Community is dormant to non-existent.
**Component coupling:** Depends on the project, but in practice often
standalone spaghetti.
**Main benefits:** Doesn’t cost anything to run.
**Typical governance:** None.
@evanleibovitch @quaid @jcanovasi Please add analysis in the comments below.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/9Upstream Dependency Archetype2021-11-10T14:31:35ZBeth HancockUpstream Dependency Archetype**Characteristics:** Intended as a building block for other software, so the user base is
made up of developers, and adoption means third-party integration of your software
into their products.
For smaller or more specialized libraries,...**Characteristics:** Intended as a building block for other software, so the user base is
made up of developers, and adoption means third-party integration of your software
into their products.
For smaller or more specialized libraries, this is a bit like Wide Open, but the experience
for maintainers and contributors is qualitatively different. When a significant portion of the
user base is able to participate technically, a lot of attention and investment may be needed
from each serious participant just to take part in discussions, even when the number of
parties in a discussion is small. Relative to Wide Open, there are fewer one-off or lightweight
contributors and more ongoing, engaged contributors.
The degree of the software’s specialization does not necessarily dictate how much
investment it receives. Upstream Dependency projects attract technical investment based
on two factors: their replaceability (it’s easier to duplicate or find an alternative for a six line
JavaScript library than it is to do so for, say, all of OpenSSL), and which downstream projects
depend on them.
Therefore understanding who is using the project, and how, is key to knowing what goals
the project can serve for Mozilla. An Upstream Dependency project can be quite influential
thanks to its role in downstream dependees, even if only a small minority of developers in
those dependees are familiar with it.
**Examples:** OpenSSL, WebKit
**Licensing:** Typically non-copyleft.
**Community standards:** Welcoming, and specifically amenable to one-time
contributions.
**Component coupling:** Standalone, decoupled from one another and the downstream
projects that pull them in.
**Main benefits:** Connections to many downstream dependee projects offers insight
into market and usage trends, and can provide openings to potential partners.
**Typical governance:** Informal, maintainer-led, committer groups.
@quaid @evanleibovitch @jcanovasi Please provide analysis in the comments.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/8Trusted Vendor Archetype2021-11-10T14:20:42ZBeth HancockTrusted Vendor Archetype**Characteristics:** Overall project direction steered by a central party — usually the founding
organization — but with encouragement of an active commercial ecosystem based on the
project, thus requiring occasional restraint or non-com...**Characteristics:** Overall project direction steered by a central party — usually the founding
organization — but with encouragement of an active commercial ecosystem based on the
project, thus requiring occasional restraint or non-competitive behavior on the part of the
primary maintainer.
The guiding principle behind the Trusted Vendor archetype is that nobody can build
everything. Sometimes people just want a complete solution from a vendor. Switching costs
for such products are often high, so choosing a proprietary solution could lock one into a
technology and a vendor. That lock-in and the related dependence gives vendors power over
their customers and users, which allows vendors to overprice and underdeliver. Customers
and users too often find themselves trapped in a relationship that doesn’t meet their needs
and sometimes feels abusive.
Open source is the antidote to vendor lock-in. First, it enables competition. If a vendor
fails or pivots or suddenly raises prices, a functioning open source ecosystem can provide
a replacement without high switching costs. Second, open source ecosystems tend toward
open standards. Integration, custom development, or even switching all come easier, faster
and cheaper if the underlying solution makes good use of common standards.
This connection between open source and risk-free vendor dependence is strong enough to
shift customer preferences. More and more procurement processes are aimed at open source
solutions precisely because they avoid lock-in during long-term vendor relations.
There are other elements of trust besides just defusing the threat of lock-in. Some of the
benefits described for the “Wide Open” archetype are also present in Trusted Vendor. In the
latter case, though, those benefits are often mainly signaling mechanisms: even if customers
never take direct advantage of the available collaboration mechanisms, they are reassured by
the existence of those mechanisms.
However, as products mature, fulfilling the promise of those mechanisms can become a
prerequisite for jump-starting the third-party vendor and integrator ecosystem, which may
eventually cause a project to shift to something more like the Multi-Vendor Infrastructure
archetype. In Trusted Vendor projects, the primary maintainer retains more control over
project direction than in Multi-Vendor Infrastructure. The commitment to being an honest
broker requires the maintainer to make certain commitments about what it will and won’t do
with that control, both in terms of the project’s technical roadmap and in terms of allowing
— indeed, encouraging — other vendors to flourish by basing their own services on the
software. A Trusted Vendor must actively avoid exclusive or monopoly powers and even avoid
some of the competitive privileges that usually come with being a project’s prime mover.
For Mozilla, this archetype can be an attractive differentiating advantage when building
services or infrastructure for the open Web. A deep commitment to privacy, data access, and
open standards all mesh well with the need to build trust that allows low risk dependence.
**Examples:** MongoDB, Hypothes.is, Coral
**Licensing:** Can be copyleft or non-copyleft; copyleft is often used to discourage
competition from forking.
**Community standards:** Users and contributors have input to roadmap, though they
may not contribute directly.
**Component coupling:** Tightly coupled.
**Main benefits:** User community — including deployers and commercial support
vendors — tends to be long-term, which provides both stability and word-of-mouth
marketing to the project.
**Typical governance:** Maintainer-led by the vendor.
@jcanovasi @quaid @evanleibovitch Please provide evaluation in the comments.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/7Specialty Library Archetype2021-11-10T14:31:36ZBeth HancockSpecialty Library Archetype**Characteristics:** Specialty libraries provide base functionality to a set of functions whose
implementation requires specialized knowledge at the leading edge of research. For example,
developers shouldn’t roll their own crypto or cod...**Characteristics:** Specialty libraries provide base functionality to a set of functions whose
implementation requires specialized knowledge at the leading edge of research. For example,
developers shouldn’t roll their own crypto or codecs; instead, everyone benefits from easy
access to a pooled set of code built by experts.
These libraries are fairly commoditized, as the set of capabilities for such a library is fairly
fixed. Any ssl or mp4 library is going to do roughly the same thing. Competing libraries might
differ at the API level, but there is no arms race over features. Given the lack of opportunity
for competitive advantage in developing one’s own library, most of those capable of
contributing have every reason to do it as part of an open source project that shares pooled
development costs and benefits.
Widespread adoption of a specific open source library can power standardization work and
also increase adoption of formal and informal standards. Coupled with careful approaches to
patents, this can open up access to participants who aren’t attached to companies with deep
pockets and large patent portfolios.
Specialty libraries look like open source projects with high barriers to entry. Anybody
can submit a patch, but landing it might require a high degree of expert work before it is
accepted into core. Coding standards are high. There is often less developer outreach and
hand-holding of new developers as participants are largely assumed to be experienced and
capable. In a heavily patented area or one subject to export controls, acceptance policies
might be more complex and even involve legal review.
**Examples:** libssl, libmp4
**Licensing:** Usually non-copyleft.
**Community standards:** High barriers to entry, largely because contributors are
expected to be experts.
**Component coupling:** Tightly coupled. These libraries are structured to do
one thing well.
**Main benefits:** Ensures a shared solution to a specific technical problem.
Cooperation at the engineering level can lead to new organizational partnerships.
**Typical governance:** Formal committer group that can grant committing
privileges to new contributors.
@quaid @jcanovasi @evanleibovitch Please add feedback in comments below.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/6Mass Market Archetype2021-11-10T14:20:42ZBeth HancockMass 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 opin...**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.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/5Wide Open Archetype2021-11-10T14:30:07ZBeth HancockWide Open Archetype**Characteristics:** Wide Open projects actively welcome contributions from any source, and
tend to get contributions at all levels: from individual developers providing one-off bug fixes
to sustained organizational contributors developi...**Characteristics:** Wide Open projects actively welcome contributions from any source, and
tend to get contributions at all levels: from individual developers providing one-off bug fixes
to sustained organizational contributors developing major features and being involved in
long-range project planning.
A Wide Open project values investing in contributors relatively highly: the core development
team is generally willing to pay a high opportunity cost (in terms of code not written or
bugs not fixed) in order to encourage or onboard a promising new contributor. The project’s
collaboration tools and processes reflect this prioritization. For example, the experienced
developers in the project will still take the time to hold design discussions in forums-of record — even when many of the individuals concerned are co-located and could make the decisions in person — in order to publicly reinforce the possibility of participation by any other self-nominated interested party.
Wide Open is a good archetype for projects that aim to serve the same technical purpose
over a long period of time, and for which stability and reliability are more important than
rapid development of the code base or fast adoption of field-specific innovations. Wide Open
is also especially effective when some significant percentage of the user base is technically
oriented (and thus susceptible to being converted to contributors), and when regular contact
with a broad developer base is likely to bring real-world usage information that would be
difficult for Mozilla to acquire in any other way.
Wide Open projects should expect the majority of contributors to be only lightly involved
making the occasional small-scale contribution here and there, but not investing heavily in
the project. A much smaller number of contributors will participate with higher degrees of
intensity. Contributors tend to cycle in and out of these groups over time, and one of the
strengths of the Wide Open archetype is that it makes it easy (from the contributors’ point
of view) for that cycling to happen, because the project as a whole is willing to sustain the
overhead of maintaining permanent “on-ramps” to greater involvement.
In general, Wide Open projects usually settle on multi-party governance in some roughly
democratic form. This is because when there are many contributors, some of them will expect
to be able to climb the influence ladder by investing time and making quality contributions.
Even for those who don’t seek that climb, the knowledge that it’s available – i.e., that past
investment could, at some future point, be retroactively incorporated into a larger strategy of
influence – is part of what makes working in a Wide Open project appealing.
In some ways the Linux kernel project could be considered “Wide Open”. However, both technically and culturally, Linux kernel development is sui generis and we have deliberately avoided using it as the basis for any archetype.
It is still possible for a single organization to retain significant and possibly decisive influence
in a Wide Open project. The typical way to do so is to invest the most developer time.
However, when an organization chooses that course, it must then be especially careful not
to demotivate others by accidentally quashing their ability — real or perceived — to achieve
influence. Simply declaring a project “Wide Open” and being receptive to contributions is
not enough; ultimately, Wide Open projects work best when they are visibly influenceable
by input from multiple sources, although one organization may be “first among equals” and
remain able to exercise leadership in major decisions.
**Examples:** Rust (present day), Apache HTTPD
**Licensing:** Can be copyleft or non-copyleft.
**Community standards:** Very welcoming to contributors, to the point of having
formalized systems for onboarding newcomers.
**Component coupling:** This archetype applies to many technically different projects, so
the component organization could go any number of ways.
**Main benefits:** Enables large-scale collaboration. Community can become
self-sustaining, which allows the original sponsoring organization some flexibility in
deciding how involved to stay.
**Typical governance:** Group-based and more or less democratic. In practice, most
decisions are made by consensus, but voting is available as a fallback when consensus
cannot be reached. There is usually a formal committer group to approve contributions
and anoint new committers.
@evanleibovitch @jcanovasi @quaid Please add feedback in comments.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/4Controlled Ecosystem Archetype2021-11-10T14:20:42ZBeth HancockControlled Ecosystem Archetype**Characteristics:** Real community involvement, and diversity of community motivations, but
with a shared understanding that the founder (or some credible entity) will act as “benevolent
dictator”. Requires experienced open source commu...**Characteristics:** Real community involvement, and diversity of community motivations, but
with a shared understanding that the founder (or some credible entity) will act as “benevolent
dictator”. Requires experienced open source community management on part of project leaders
and occasional willingness to compromise. Works best when technical architecture directly
supports out-of-core innovation and customization, such as via a plugin system.
Controlled Ecosystem efforts find much of their value in that ecosystem. The core pro vides
base value, but the varied contributions across a healthy plugin ecosystem allow the project to
address a much larger and diverse set of needs than any one project could tackle alone. Over
time, these projects might see more and more of the core functionality structured as plugins
as the product becomes more customizable and pluggable. This increasingly lets the plugins
determine the end-user experience, and the core project can eventually become infrastructure.
**Examples:** Wordpress, Drupal
**Licensing:** Can be either copyleft or non-copyleft. When copyleft, decisions must
be made about whether the core interfaces (and maintainer-promulgated legal
interpretations) encourage or discourage proprietary plugins.
**Community standards:** Welcoming, often with structures designed to promote
participation and introduce new contributors
**Component coupling:** Loosely coupled modules, frequently in a formal plugin system.
**Main benefits:** Builds a sustainable ecosystem in which the founding organization
retains strong influence.
**Typical governance:** Benevolent dictatorship, with significant willingness to
compromise to avoid forks.
@evanleibovitch @quaid @jcanovasi Please leave any feedback in the comments below.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/3Rocket Ship To Mars Archetype2021-11-10T14:30:06ZBeth HancockRocket Ship To Mars Archetype**Characteristics:** “Rocket Ship To Mars” projects are characterized by a small full-time core
team that is wholly focused on a well-articulated and highly specific goal. They are often led
by charismatic founders and enjoy a funding ru...**Characteristics:** “Rocket Ship To Mars” projects are characterized by a small full-time core
team that is wholly focused on a well-articulated and highly specific goal. They are often led
by charismatic founders and enjoy a funding runway sufficient for bootstrapping. Their open
source strategy is often rooted in a commitment to transparency and providing insurance:
they want to instill confidence among developers and users in order to promote adoption,
and being open source is one ingredient in doing that.
Rocket Ships To Mars tend toward non-copyleft licensing when their goal is broad adoption
by the tech industry at large, but may use copyleft licensing when aiming for deployment and
usage scenarios where there is no particular advantages to non-copyleft. (For example, Signal
notes that their use of the GPL-3.0 license is primarily for “quality control”8
.) In any event, Rocket Ships To Mars tend not to play well with others. Every ounce of fuel goes to thrusters, which leads little energy left over for the hard work of nurturing a contributor community.
Rocket Ships To Mars typically do not invest a lot of effort in encouraging broad
contributorship, not so much because they wouldn’t welcome contributions as because it
is hard to find contributors who share the project’s intensity and specificity of vision, and
who are sufficiently aligned with the founders to take the time to make their contributions
fit in. These projects are also usually trying to reach a convincing alpha release as quickly
as possible, so the tradeoff between roadmap speed and contributor development looks
different for them than for other types of projects.
Similarly, the components of such projects are generally tightly coupled: their goal is not to
create an ecosystem of plug-and-play modules, but to create one core product that can be
marketed as a standalone service.
The biggest challenge for Rocket Ship To Mars projects is usually to detect and take
advantage of the right organizational collaboration opportunities. Some strategic
partnerships are worth sacrificing momentum for, especially when they could affect the
project’s direction early on.
Part of the purpose of specifying this archetype is to help Mozilla give itself permission to
run projects like this when appropriate. There are times when Mozilla may want to press
forward to some goal and not stop (at least for a while) to deal with other participants.
At the very least, the people advocating for this should have a model to point to, and the
people arguing against it should have a clear idea of what it is they’re arguing against.
When a Rocket Ship To Mars project is launched, it is important to set public expectations
accurately. Some observers will be interested in going to Mars, and some will not be, but at
least when there is clear messaging each observer can make an informed decision about
how much to invest in following the project or in aligning themselves with it sufficiently to be
able to participate on Mozilla’s terms.
**Examples:** Meteor, Signal
**Licensing:** Usually non-copyleft, but may be copyleft under certain circumstances.
**Community standards:** Difficult to enter; focused on the core group.
**Component coupling:** Tight, in order to ship one core product.
**Main benefits:** Achieves a quick, focused effect on a specific area; if successful,
can co-opt competition.
**Typical governance:** Maintainer-led by the founding group.
@quaid @jcanovasi @evanleibovitch Please add feedback and insights in the comment area below.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/2Multi-Vendor Infrastructure Archetype2021-11-10T14:20:42ZBeth HancockMulti-Vendor Infrastructure Archetype**Characteristics:** Multi-Vendor Infrastructure are large software projects that provide
fundamental facilities to a wide array of other businesses. This infrastructure is designed
collaboratively by multiple vendors and then each deplo...**Characteristics:** Multi-Vendor Infrastructure are large software projects that provide
fundamental facilities to a wide array of other businesses. This infrastructure is designed
collaboratively by multiple vendors and then each deploys it in their own way. Kubernetes
and OpenStack are two prominent Multi-Vendor Infrastructure projects that most developers
will have heard of.
Multi-Vendor Infrastructure efforts are driven by business needs rather than individuals, and
are open to relatively lightweight participation. A good way to distinguish a Multi-Vendor
Infrastructure project from Business-to-Business (B2B) Open Source is to look at how often
contributors continue to participate after they switch employers. When that phenomenon
occurs, it indicates that multiple organizations use the software as infrastructure in roughly
the same way, and thus the same person may continue representing those technical
priorities across different organizations.
In other words, the difference between this and B2B Open Source is that less organizational
and process overhead is required to take part — enough so to make participating a
qualitatively different proposition. For example, individual developers are generally more able
and more likely to make contributions to Kubernetes and OpenStack than they are to Android,
but they still tend to do so from organizational rather than from individual motivation. These
organizational motivations often relate to tactical needs, and may be enabled by midlevel management decisions. By contrast, B2B open source tends to be driven by corporate business strategy, and is thus more likely to figure into executive-level decisions.
What this means for Mozilla is that if Mozilla clearly understands who within its potential
partners is authorizing participation, then Mozilla will be much better positioned to tune the
project’s collaboration processes — and related things like conference appearances, media
strategies, further partner discovery, etc. — so as to maximize the benefit to Mozilla’s mission.
**Examples:** Kubernetes, Open Stack
Note that both the Multi-Vendor Infrastructure and the B2B Open Source archetypes are
patterns that achieve benefits at scale. They are also patterns that provide infrastructure
to enable a varied set of third-party activity. The largest advantage of open source to these
ecosystems is broad standardization (including informal or de facto standardization). Both
the container world and the cloud ecosystem provide a set of tools and pieces that can
be combined together in standard ways to provide custom solutions. That standardization
is necessary to allow reconfiguration and customization. It drives adoption at scale, and,
in a virtuous circle, the scale is what creates the de facto standards. It would be difficult
to achieve this dynamic with a proprietary approach; open source lowers the cost of
participation and powers network effects that lead to scale.
**Licensing:** Typically non-copyleft, given that many members of the
community are likely to maintain proprietary forks of the core product.
**Community standards:** Welcoming, but formal, and often difficult for individual
contributors to enter. Participation takes a high level of resources.
**Component coupling:** Loosely-coupled modules joined by de facto standards.
**Main benefits:** Fosters collaboration with partner organizations to solve
shared problems.
**Typical governance:** Formal tech committee, with membership by each of
the major contributing companies.
@evanleibovitch @jcanovasi @quaid Please provide feedback in the comments.http://opensource.ieee.org/community-advisory-group/open-comm-dev-models/meetings/-/issues/1Business-to-Business (B2B) Open Source Archetype2021-11-10T14:20:40ZBeth HancockBusiness-to-Business (B2B) Open Source Archetype**Characteristics:** Solid control by founder and (sometimes grudging) acceptance of
unpredictability by redistributors. This also implies a long fork-modify-merge cycle for
partners, and thus a constant temptation on their part to fork ...**Characteristics:** Solid control by founder and (sometimes grudging) acceptance of
unpredictability by redistributors. This also implies a long fork-modify-merge cycle for
partners, and thus a constant temptation on their part to fork permanently.
This archetype aims at ubiquity. Its open source nature is designed to spur OEM adoption
by partners and competitors across the industry and to drive out competing options in the
same way pricing browsers at zero once discouraged new entrants into the browser market. It
can also drive down the price of complementary products: for example, as Red Hat Enterprise
Linux (RHEL) does for server hardware and Google’s Android operating system does for
handheld devices.
It is worth noting that Google does not derive much direct revenue from Android. Instead,
Android’s popularity puts Google’s products and search preferences in the hands of users,
and that creates opportunities for Google. Android users default to Google’s search engine,
buy media from Google, pay for apps in Google’s app store, provide a river of data for Google
to mine, and favor Google’s app ecosystem (Calendar, Gmail, Maps, etc). All of that generates
revenue and strategic advantage for Google. This archetype is thus a strategy for gaining
marketshare as a revenue opportunity.
This model probably works best when run by a fairly large company with multiple ways
of applying market pressure and multiple channels for distribution. It is difficult to wield
without considerable financial resources and other strategic advantages.
**Licensing:** Almost always non-copyleft.
**Community standards:** In general, the lead company does not put much emphasis
on welcoming or nurturing contributors; exceptions may be made for strategically
important organizational partners.
**Component coupling:** Tightly coupled modules, to allow the lead
company to market one unified product.
**Main benefits:** Can drive industry adoption of a technology that
is strategically important to your organization.
**Typical governance:** Maintainer-led by a group within the lead company.
**Examples:** Android, Chromium
**Compare to:** with the Mass Market archetype, which can have similar effects on directly competitive products but is less likely to affect complementary products.
@evanleibovitch @jcanovasi @quaid Please provide feedback in the comments.