HackMD
OSS Developent Coordination Exploration
Motivation
Recently I was pondering "How complex is Ethereum Core Protocol Software Development?" and the following picture popped into my head:
The thought process that spurred this was roughly: What is the least complex OSS development body? Probably a 2 person group chat. And Ethereum EIP and Core Dev is likely 75% away from 2 person group chat on the spectrum of complexity.
But before I could start adding more OSS development bodies I realized this view is likely too limited, so I further decomposed it into two features, the number of contributors and the complexity of the "process".
This lead me to refine my ideas to three basic questions:
- What coordination structures exist between Ethereum Core Develpment and a 2 Person Group Chat, and beyond?
- What are the similiarities, differences, and unique features between the most popular OSS development bodies?
- Bonus What technologies do these groups use?
Fact Finding
Before attempting to answer the questions in the motivation I went on a fact finding mission to explore the largest OSS development bodies I could think of:
- Java Community Process (JCP)
- Python Enhancement Proposals (PEP)
- Bitcoin Improvement Proposals (BIP)
- Ethereum Improvement Proposals (EIP)
- TC39 ECMA
- Linux Kernel Development
- Internet Engineering Task Force (IETF)
But this list certainly isn't exhaustive. Please let me know if there are others I should consider reader.
Java Community Process (JCP)
What is the Goal of the Process?
“The JCP is the mechanism for developing standard technical specifications for Java technology.”
How Does the Process Work?
The Java Community Process (JCP) Program is the process by which the international Java community standardizes and ratifies the specifications for Java technologies. The JCP ensures high-quality specifications are developed using an inclusive, consensus-based approach. Specifications ratified by the JCP, must be accompanied by a Reference Implementation (to prove the Specification can be implemented), and a Technology Compatibility Kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the Specification). Experience has shown that the best way to produce a technology shown that the best way to produce a technology specification is to use an open and inclusive process to co-develop a specification and implementation, informed by a group of industry experts with a variety of viewpoints, community and public opportunities to review and comment and a strong technical lead to ensure both the technical goals and integration with other relevant specifications and user expectations.
An Executive Committee (EC) representing a cross-section of both major stakeholders and other members of the Java community is responsible for approving the passage of specifications through the JCP's various stages and for reconciling discrepancies between Specifications and their associated test suites.
There are four major stages in this version of the JCP:
- INITIATION: A Specification targeted at the desktop/server or consumer/embedded space is initiated by one or more Members and approved for development by the EC. A group of experts is formed to assist the Spec Lead with the development of the Specification.
- DRAFT RELEASES: The Expert Group develops the Specification, releasing drafts for public review and comment. After the formal Public Review the EC holds a ballot on whether the JSR
should proceed to the Final Release stage.- FINAL RELEASE: The Spec Lead submits the Specification to the PMO for publication as the Final Release when the RI and TCK are completed, and the RI passes the TCK, the Specification, the RI, and the TCK are submitted to the PMO, which circulates them to the EC for review.
- MAINTENANCE: The Specification, Reference Implementation, and Technology Compatibility Kit are updated in response to ongoing requests for clarification, interpretation, enhancements, and revisions. The EC reviews proposed changes to the Specification and indicates which can be carried out immediately and which should be deferred to a new JSR.
This version (2.11) of the JCP was developed using the Java Community Process itself by means of JSR 387, which was led by Oracle with all Executive Committee members forming the Expert Group.
Estimated Size
Approximately 1,500 members.
Python Enhancement Proposals (PEP)
What is the Goal of the Process?
“PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python.”
- How Does the Process Work?
“There are three kinds of PEP:
- A Standards Track PEP describes a new feature or implementation for Python. It may also describe an interoperability standard that will be supported outside the standard library for current Python versions before a subsequent PEP adds standard library support in a future version.
- An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementers are free to ignore Informational PEPs or follow their advice.
- A Process PEP describes a process surrounding Python, or proposes a change to (or an event in) a process. Process PEPs are like Standards Track PEPs but apply to areas other than the Python language itself. They may propose an implementation, but not to Python’s codebase; they often require community consensus; unlike Informational PEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Python development. Any meta-PEP is also considered a Process PEP.
There are several references in this PEP to the “Steering Council” or “Council”. This refers to the current members of the elected Steering Council described in PEP 13, in their role as the final authorities on whether or not PEPs will be accepted or rejected.”
Estimated Size
Approximately 3,000 contributors.
Bitcoin Improvement Proposals (BIP)
-
What is the Goal of the Process
A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature.
We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
This particular BIP replaces BIP 1 with a more well-defined and clear process.
-
How Does the Process Work
People wishing to submit BIPs, first should propose their idea or document to the bitcoindev@googlegroups.com mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. Having a BIP here does not make it a formally accepted standard until its status becomes Final or Active. …
There are three kinds of BIP:
- A Standards Track BIP describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin. Standards Track BIPs consist of two parts, a design document and a reference implementation.
- An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors are free to ignore Informational BIPs or follow their advice.
- A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Standards Track BIPs but apply to areas other than the Bitcoin protocol itself. They may propose an implementation, but not to Bitcoin's codebase; they often require community consensus; unlike Informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a Process BIP.
Estimated Size
Approximately 800 contributors.
Ethereum Improvement Proposals (EIP)
-
What is the Goal of the Process
What is an EIP?
EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.
EIP Rationale
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
-
How Does the Process Work
The status page tracks and lists EIPs, which can be divided into the following categories:
- Core EIPs are improvements to the Ethereum consensus protocol.
- Networking EIPs specify the peer-to-peer networking layer of Ethereum.
- Interface EIPs standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.
- ERCs specify application layer standards, which determine how applications running on Ethereum can interact with each other.
- Meta EIPs are miscellaneous improvements that nonetheless require some sort of consensus.
- Informational EIPs are non-standard improvements that do not require any form of consensus.
Before you write an EIP, ideas MUST be thoroughly discussed on Ethereum Magicians or Ethereum Research. Once consensus is reached, thoroughly read and review EIP-1, which describes the EIP process.
Estimated Size
Approximately 1,000 contributors.
TC39 ECMA
-
What is the Goal of the Process
“Ecma International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.
-
How Does the Process Work
TC39 welcomes contributions from the JavaScript community, whether it is feedback on existing proposals, improved documentation, testing, implementations, or even language feature ideas. See our contributor guide for details. We develop the JavaScript (formally, ECMAScript) specification on GitHub and meet every two months to discuss proposals. To learn more about the process, please take a look at the six stages for new language feature proposals. See our meeting agendas and minutes to learn more.
Proposals follow the TC39 process and are tracked in the proposals repository.
Estimated Size
Approximately 600 active members.
Linux Kernel Development
-
What is the Goal of the Process
“The purpose of this document is to help developers (and their managers) work with the development community with a minimum of frustration. It is an attempt to document how this community works in a way which is accessible to those who are not intimately familiar with Linux kernel development (or, indeed, free software development in general). While there is some technical material here, this is very much a process-oriented discussion which does not require a deep knowledge of kernel programming to understand.”
-
How Does the Process Work
“How the development process works introduces the development process, the kernel release cycle, and the mechanics of the merge window. The various phases in the patch development, review, and merging cycle are covered. There is some discussion of tools and mailing lists. Developers wanting to get started with kernel development are encouraged to track down and fix bugs as an initial exercise.”
Estimated Size
Over 4,000 contributors.
Internet Engineering Task Force (IETF)
-
What is the Goal of the Process
"the overall goal of the IETF is to make the Internet work better."
"Its mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds."
-
How Does the Process Work
RFCs
The IETF publishes its technical documentation as RFCs, an acronym for their historical title Requests for Comments. RFCs are sequentially numbered, starting with RFC 1 published in 1969 (the RFC series predates the IETF). Each RFC has a status, generally one of 'Internet Standard', 'Proposed Standard', 'Best Current Practice' (or 'BCP' in short), 'Informational', 'Experimental' or 'Historic'. Some statuses may change over time. RFCs are freely available.
The RFC series has two sub-series, STDs and BCPs, with each numbered STD and BCP comprising one or more RFCs. STDs are 'Internet Standard' RFCs and BCPs are RFCs that describe Best Current Practices in the Internet, some of which are administrative processes for the IETF.
Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that "obsoletes" the first. If a technical or editorial error is found in an RFC, an errata may be linked to the RFC and/or held for the next document update.
…
IETF Meetings
The IETF holds three week-long meetings a year with the primary goal of helping Working Groups get their tasks done, and promoting cross-WG discussions. In-person participation at IETF meetings now averages between 1000 and 1500 participants, with hundreds of additional participants joining remotely. These meetings rotate around the globe.
Estimated Size
Approximately 7,000 active participants.
Questions
Question 1: What coordination structures exist between Ethereum Core Development and a 2-Person Group Chat, and beyond?
There are numerous coordination structures that exist between the simplicity of a two-person group chat and the complexity of Ethereum Core Development. These can be characterized by their organizational, procedural, and communication mechanisms. Here's a spectrum of coordination structures with increasing complexity:
-
Small Team Collaboration:
- Organizational: Defined roles (e.g., lead, contributors).
- Procedural: Regular meetings, simple task tracking.
- Communication: Group chat, shared documents.
-
Open Source Project (Small Scale):
- Organizational: Maintainer, contributors, occasional reviewers.
- Procedural: Issue tracking, code reviews, pull requests.
- Communication: GitHub/GitLab issues, email lists.
-
Mid-Sized Open Source Project:
- Organizational: Core team, external contributors, reviewers.
- Procedural: Regular releases, roadmap planning, structured code review.
- Communication: GitHub/GitLab, mailing lists, forums.
-
Large Open Source Project (e.g., Python PEPs):
- Organizational: Steering Council, core developers, external contributors.
- Procedural: Enhancement proposal process, regular meetings, community input.
- Communication: GitHub, Discourse forums, mailing lists.
-
Standards Body (e.g., JCP, IETF):
- Organizational: Executive committee, working groups, large contributor base.
- Procedural: Multi-stage proposal process, public reviews, formal ballots.
- Communication: Mailing lists, official meetings, conference calls.
-
Decentralized Development (e.g., Ethereum EIPs):
- Organizational: Community-driven, core developers, working groups.
- Procedural: Improvement proposal process, community consensus, core dev meetings.
- Communication: Forums (Ethereum Magicians), GitHub, research groups, regular dev calls.
-
Corporate-Led Open Source (e.g., Linux Foundation Projects):
- Organizational: Governing board, technical steering committee, maintainers.
- Procedural: Structured governance, funding, strict code review policies.
- Communication: Mailing lists, dedicated collaboration tools, regular summits.
Plotting each of the research bodies on the original we get:
Question 2: What are the similarities, differences, and unique features between the most popular OSS development bodies?
The various OSS development bodies share fundamental principles but differ in their structures, processes, and unique characteristics.
Similarities:
-
Consensus-Based Decision Making:
- Most OSS bodies use a consensus-based approach to decision-making (e.g., JCP, PEPs, EIPs).
-
Open and Inclusive Processes:
- All bodies emphasize openness and inclusiveness, allowing contributions from a broad community (e.g., TC39, IETF).
-
Documentation and Transparency:
- Processes are well-documented and transparent, with historical records maintained (e.g., BIPs, EIPs).
Differences:
-
Formality and Structure:
- Bodies like the JCP and IETF have highly formal and structured processes with multiple review stages.
- Less formal bodies like BIP and PEP have more flexible processes with fewer mandatory stages.
-
Governance and Authority:
- JCP and IETF have executive committees or working groups with final authority on decisions.
- PEPs are overseen by a Steering Council.
- EIPs rely on community consensus and Core Dev meetings for final decisions.
- TC39 uses a committee of experts and community input.
- Linux Kernel follows a more meritocratic model with maintainers having significant influence.
Unique Features:
-
JCP:
- Executive Committee for approval and governance.
-
PEP:
- Three distinct types of PEPs (Standards Track, Informational, Process).
-
BIP:
- Community-driven with a focus on maintaining a decentralized decision-making process, influenced by PEP.
-
EIP:
- Diverse categories addressing different layers of the Ethereum ecosystem (Core, Networking, Interface, ERC, Meta, Informational), inspired by both PEP and BIP.
-
TC39:
- Six-stage process for evolving JavaScript features.
-
Linux Kernel:
- Highly meritocratic with an emphasis on code quality and peer review.
-
IETF:
- Use of RFCs with a long historical tradition and global meetings for coordination.
It is interesting to note that BIP and EIP are both modeled after PEP.
Question 3: What technologies do these groups use?
-
JCP:
- Collaboration platforms: JCP Website, GitHub.
- Issue tracking: JIRA.
- Communication: Mailing lists, conference calls.
-
PEP:
- Collaboration platforms: GitHub.
- Communication: Mailing lists, Discourse forums.
- Issue tracking: GitHub Issues.
-
BIP:
- Collaboration platforms: GitHub.
- Communication: Mailing lists, GitHub PRs.
- Issue tracking: GitHub Issues.
-
EIP:
- Collaboration platforms: GitHub.
- Communication: Ethereum Magicians, Ethereum Research forums.
- Issue tracking: GitHub Issues.
-
TC39:
- Collaboration platforms: GitHub.
- Communication: GitHub, committee meetings.
- Issue tracking: GitHub Issues.
-
Linux Kernel
- Collaboration platforms: Git repositories.
- Communication: Mailing lists (LKML), patch submissions.
- Issue tracking: Bugzilla, mailing lists.
-
IETF:
- Collaboration platforms: Datatracker, GitHub.
- Communication: Mailing lists, IETF meetings.
- Issue tracking: Datatracker, mailing lists.
