Earlier this year I confronted the painful realization that my baby framework grew into a mature ecosystem – one I no longer had the capacity to maintain on my own. It started with dragging open issues for more than a few days, to a growing pile of sticky notes on my monitor of ideas I’d like to try, to (and most problematic) no longer remembering how big chunks of the code work.
The problem is, how to successfully move from a one-man-show to a community driven project, without giving up on the stability, consistency, and philosophy of the framework.
I believe the only practical model for running a successful open source project is the Consensus-Dictator-Fork (CDF) model. It’s a fancy name for how most open source projects work. Decisions are made by consensus whenever possible. This usually covers 95% of the decisions by the simple mechanism of proposing a change and asking for strong objections. When strong objections are raised and consensus does not emerge, the project BDFL (benevolent dictator for life) makes the final call. If enough people object to that decision, they fork the project and create their own. It is a naturally self-balancing system.
CDF doesn’t solve the problem, but it provides the first building block.
Federation of Modules
The second building block is npm, the package management service. npm makes it trivial to break a large system into smaller modules, each with its own owners and publishing schedule. Instead of applying CDF to the entire ecosystem, I realized I can apply it individually to each module the framework consists of. Each module author has the autonomy to drive their module forward, allowing its dependents to vote with their feel (i.e. package.json files) and switch to another module if they don’t like the changes and fail to influence through consensus.
The smaller the surface area of the hapi module is, the more time I have to focus on the problems I care most about, and the more power is being delegated to other people to drive the many different areas of the framework forward. This is not just about which utilities we use, but about moving core functionality out of the main module. It redefines “core” from the top-level module people require, to the collection of modules used.
The Right People
Before splitting the hapi module into many smaller pieces, I had to identify who is going to take over these new modules. What profile am I looking for. After all, big chunks require more experience while smaller chunks increase the need to communicate. The answer to that was simple, but non-intuitive: everyone who is interested in contributing.
The reason this is non-intuitive is because we are stuck thinking about open source contributions and ownership in terms of merit and meritocracy. These are extremely unhelpful terms and for too many people they translate to “the rich keep getting richer”. Open source meritocracy is supposed to be about letting proven people lead, but in practice it creates a chicken-and-egg problem of making it virtually impossible for new leaders.
I wanted to make participation and leadership within the hapi.js community to be truly open to everyone who is committed to making a contribution. This requires two things: that no one feels excluded or unwelcomed (for any reason), and that everyone feels they are good enough to step up.
Leading a successful open source project often translates to increased professional success, which in turn translates to more money, influence, freedom, and happiness. It is far easier to find a great engineering job with a famous open source project on your resume. Having a project on npm with 100K daily downloads can open doors 10 years of experience sometimes can’t. Numbers might not get you the job but they will get you through the door.
The best way to make open source sustainable is to make it rewarding. By extending the invitation to lead to others, we create opportunity and rewards that are otherwise very hard to achieve. It is far easier to take over an open source project with existing user base and traction than to start from scratch and battle for attention. The long tail is a lonely place.
Leap of Courage
So how do we convince people to make that leap? To take over a popular open source module and lead it, in public, where every mistake is visible and often amplified? How do we make them feel comfortable to try new things and take risks? And how do we trust them not to screw up? Simple – by having their back.
npm shrinkwrap is not just a command line tool. It is an instrument of social change. By locking down the proven, trusted, stable versions of the framework dependencies, module leads can make mistakes without devastating consequences. By putting safeguards in place to prevent instability, we can hand over core building blocks of the framework to people without demanding “proven track record” or “merit”. We no longer need to be exclusive in who we invite to join our round table, and if it really doesn’t work out, CDF to the rescue.
Putting risk controls is half the solution. We can’t throw people into the deep end with a lifesaver and expect them to get better at swimming. It is not enough to protect the ecosystem. We have to nurture and grow it. The other half of the solution is the new hapi.js mentoring program. By assigning new contributors and leads an experienced, one-on-one mentor, we increase their confidence and skill, and create a mutually rewarding environment where contributions get exponentially better.
The mentorship program is brand new, but it was based on extensive research and conversations with people to ensure a welcoming, safe, and diverse environment.
With everything in place, I spend the last two months smashing hapi into about 20 new modules, all looking for a new lead maintainer. With version 7.1.0 we are now all set to embark on this new, wide open community strategy.
If you ever wanted to participate in a large, meaningful, and highly visible open source project, but did not feel confident (or safe), this is your cue. We are transforming a successful project on its head with the sole criterion of making it a welcoming place for everyone. I am sure we got plenty to improve and iterate on, but the groundwork has been laid, and the doors are open.