choldgraf
commented
5 years ago 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 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).
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:
- If we had 100% points to give out to all of these categories, how would they be divided?
- This is an attempt at description, not prescription. What do people think Jupyter should be in its goals?
- What kind of challenges or opportunities do each of these models have for sustainability in the Jupyter community?
- Given thoughts in 2 and 3, what are some things we, as a community, should be doing differently?
ellisonbg
jasongrout
Ruv7
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