Engineer at Mapbox, creator of Leaflet, open source enthusiast, algorithms geek, speaker, singer-songwriter (Obiymy Doschu), father of twin girls, Ukrainian
Describing a set of simple core principles and goals of a project from the start helps a lot (e.g. in a readme or a contributing file). For Leaflet, the goal was to create the simplest, fastest and lightest mapping library that anyone could use — it's easy to align decisions with a simple, measurable goal like this (even if you have to reject contributions sometimes).
It's also important to keep a project focused — a small library that covers 90% of use cases in a specific, narrowly defined area is orders of magnitude easier to maintain than a big one that tries to cover 100%. That means learning to reduce the scope, say no to new features, and proactively work on simplifying the project.
Got tips for managing an open source community in terms of project direction, expectations, etc?
Describing a set of simple core principles and goals of a project from the start helps a lot (e.g. in a
readmeor acontributingfile). For Leaflet, the goal was to create the simplest, fastest and lightest mapping library that anyone could use — it's easy to align decisions with a simple, measurable goal like this (even if you have to reject contributions sometimes).It's also important to keep a project focused — a small library that covers 90% of use cases in a specific, narrowly defined area is orders of magnitude easier to maintain than a big one that tries to cover 100%. That means learning to reduce the scope, say no to new features, and proactively work on simplifying the project.
Thanks!