No Project Scope Survives Contact with Users - 2026
(link)Summary
Min Ragan-Kelley discusses the challenges of maintaining a defined scope in large, community-driven open-source projects, using the evolution of the Jupyter ecosystem (IPython, JupyterLab, JupyterHub) as a detailed case study. He emphasizes that defining what a project *is* as much as defining what it *does* is crucial for sustainable development.
Key Takeaways
- Defining scope requires explicitly stating what problems the project is *not* trying to solve, which is a powerful way to manage expectations and say 'no'.
- The Jupyter architecture—separating the UI (browser) from the execution (kernel) via a web server—allowed for flexible deployment, but this flexibility led to scope creep.
- Early scope limitations (e.g., targeting small academic groups, Linux-only, no high availability) were necessary to keep the project manageable and focused.
- As the project gained adoption (from small workshops to large institutions like Berkeley), the scope naturally expanded, leading to increased complexity (e.g., Kubernetes integration, high availability requirements).
- The lesson learned is that while saying 'yes' feels good, it can incur significant long-term costs, making clear, documented scope communication essential for project health.
Sections
The Challenge of Project Scope in Open Source
Min Ragan-Kelley begins by defining 'scope' not just as what a project aims to build, but what problems it explicitly chooses *not* to solve. In open-source work, having a clear scope allows developers to say 'no' effectively and efficiently, which is vital when external users propose changes or features.
The Evolution of the Jupyter Ecosystem
The Jupyter project has grown from a simple IPython tool to a massive ecosystem managing millions of lines of code across dozens of repositories. The core architecture separates the user interface (UI) from the code execution (kernel) via a web server. This separation was initially chosen for accessibility (running on various platforms) and allowed the execution environment to be decoupled from the UI, enabling remote deployment.
Initial Scope Definition and Constraints
When JupyterHub was first developed, the scope was intentionally limited to manage complexity. Constraints included: <ul><li>**Target Users:** Small academic groups (tens of users), not large enterprises.</li><li>**Technical Limits:** Linux-only support, requiring Python 3, and avoiding complex features like high availability (HA) or advanced security mechanisms.</li><li>**Goal:** To provide a single host with a single URL/port, simplifying IT policy and deployment for users.</li></ul>These limitations were crucial for keeping the initial development effort manageable.
Scope Creep: From Academia to Enterprise
The project's adoption quickly challenged its initial scope. Early adopters (like Jessica Ham) used it for small classes, but as institutions scaled up (e.g., Berkeley's Data Hub supporting thousands of students), the requirements shifted dramatically. The community began demanding features like: <ul><li>High Availability (HA) guarantees.</li><li>Support for massive scale (thousands of users).</li><li>Integration with advanced deployment tools (e.g., Kubernetes).</li></ul>This shift forced the project to expand its scope significantly, moving from a simple tool to complex infrastructure.
Lessons in Scope Management
The talk concludes by highlighting the cost of scope creep. The initial small project became a massive undertaking, pulling the developer away from other core Jupyter work. The key takeaway is that while the desire to say 'yes' to every feature request is natural, it can impose a significant, sometimes crippling, cost on the project's focus and maintainability. Clear, documented scope communication is the most critical tool for sustainable open-source development.
Keywords: jupyterhub, ipython, open source development, project scope management, software architecture, kubernetes, web server, academic computing