1. 11

  2. 8

    Funny to see this given the project and its strategy failed while Pieter’s strategy and project succeeded. People should be submitting his instead given it got results. Here’s the post-mortem followed by Pieter’s commentary on it:



    1. 6

      That first link is one of the best summations of project community governance patterns and anti-patterns I have ever read. Thank you.

      Rule: the success of a project requires contributors entering the project at least as fast as they leave. As long as contributors are at least “exactly replaced”, the project remains stable. But if fewer contributors enter than leave, the project enters a death sprial as contributions shrink and eventually become zero.

      Technology, politics, social factors, governance, and more all play a role in the rate of attracting new contributors or pushing out existing ones. But they are merely knobs, of selecting for one kind of person over another. Projects can and do exist without sound technical or social policy. They cannot exist without contributors.

    2. 5

      First, by its nature, piece of software is not a social club. It’s a technical artifact that’s reliable or buggy, fast or sluggish, maintainable or a tangle of spaghetti code.

      This might be true for the artifact, but not for the development process, which, in my experience, is almost exclusively a social “club” (i.e., people working together). Modern software no longer stands alone: up through the 90s one could deliver a completely self-contained system, and so therefore a single person could write and deploy a system without interacting with anyone (or anyone else’s systems). Of course, most systems are used by people other than the creator of the system, so we’re back to people interacting again (for requirements, feedback, changes, etc.).