Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Researching other open communities: Governance + Structure #60

choldgraf opened this issue Oct 23, 2018 · 9 comments

Researching other open communities: Governance + Structure #60

choldgraf opened this issue Oct 23, 2018 · 9 comments


Copy link

@choldgraf choldgraf commented Oct 23, 2018

This is an issue to keep track of some "meta" research as a part of the Mozilla Open Leaders program. There are lots of open projects out there, and they've all got their own take on how to effectively organize open communities. As I read and learn more, I'll keep this issue updated with information in case others are interested or have thoughts of their own!

Interesting links

Copy link
Contributor Author

@choldgraf choldgraf commented Oct 24, 2018

I just had another read-through of the Mozilla archetypes of open source PDF and I wanted to share some thoughts about where I think Jupyter fits in. Here are a few relevant archetypes they discuss:

Rocket Ship To Mars

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 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.

Controlled Ecosystem

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.

Wide Open

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-ofrecord
— 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.

Mass market

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 (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).

My thoughts:

Totally spitballing here: I feel like Jupyter began as a "Rocketship to Mars". The core team went through many cycles of rapid development. This gave us amazing products like the Jupyter Notebook, at the cost of some good will from the developer community (in the past I'd often hear "it's so hard to keep up with developments the Jupyter community because the technology moves so fast")

In the last few years, as the products in Jupyter have matured and the community of core contributors has diversified, Jupyter has become something closer to these categories, in decreasing order:

  • a controlled ecosystem, in the sense that the Jupyter extension/plugin system is a part of the core Jupyter ideology (standards and modularity)
  • a "mass market" in the sense that many core Jupyter products provide an open-source alternative to what would otherwise be captured by proprietary products from companies
  • a "wide open" project in the sense that we've seen more emphasis in recent years on building community rather than just building features. E.g., JupyterCon, JupyterDays, improvements to documentation, improvements to team processes to make Jupyter more welcoming, etc.

I feel like we're also starting to bump up against "B2B" and "Multi-Vendor Infrastructure" models, but not necessarily in a principled way, just because of the fact that there are more large-scale organizations relying on Jupyter tech.

One other thing I'll mention is that I get the feeling this depends a lot on the particular sub-community that one is a part of. Most of my experiences are from the JupyterHub and Binder side of things, and I'd be really curious to hear what other folks think about where Jupyter falls on this scale.

I want to think about this a bit more but these are just some early thoughts. Other questions swirling in my brain:

  1. If we had 100% points to give out to all of these categories, how would they be divided?
  2. This is an attempt at description, not prescription. What do people think Jupyter should be in its goals?
  3. What kind of challenges or opportunities do each of these models have for sustainability in the Jupyter community?
  4. Given thoughts in 2 and 3, what are some things we, as a community, should be doing differently?

Copy link

@ellisonbg ellisonbg commented Oct 24, 2018

Copy link
Contributor Author

@choldgraf choldgraf commented Oct 24, 2018

@ellisonbg I'm curious to your thoughts on the set of blog posts that I just posted from the Mozilla person. They kind of get at this point, in the context of discussing "hybrid organizations" like Mozilla. It's about 10 years old and obviously much has changed since they were written, but I found it insightful nonetheless

Copy link

@ellisonbg ellisonbg commented Oct 24, 2018

Copy link
Contributor Author

@choldgraf choldgraf commented Dec 6, 2018

Hey folks - just pinging all on this thread that a member from the ropensci community is sharing some research they've done on open governance structures. It'll be in this ropensci community call here:

Copy link

@ellisonbg ellisonbg commented Dec 6, 2018

Copy link

@jasongrout jasongrout commented Dec 6, 2018

I see that Dan is a postdoc at UC Berkeley, so we might be able to talk to him outside the call as well.

Copy link

@Ruv7 Ruv7 commented Dec 6, 2018

Thanks for sharing, I look forward to listening in on this.

Copy link
Contributor Author

@choldgraf choldgraf commented Jun 2, 2019

I just noticed that Rust has their own working group on governance refactoring, might be worth looking at that process for inspiration:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants