| I'm responding to my own comment to respond to the sister comments: It seems most people who have responded seem to think I defend the kind of guy who joins an open source project, get some importance and then starts to act like a jerk (or in other words, starts challenging the power status of the main maintainer which is a natural thing once an individual invests a certain amount of time in a project). No wonder so many people react against this kind of guy. There is resentment on both sides. Now let me tell you about another kind of "maintainer", the casual one. He just goes by, fixes a bug or broadens the interface of a function and he's gone. You'll most likely never have resentment against this kind of maintainer even though he might, because you're not engaged in a power struggle against him. Why ? Because you have already won it. You just can ignore/forget about his PR he won't harass you about it anyway. For what he knows you might be dead and have carried that holy merging power with you in the afterlife. He has invested work in this, because working for the benefit of community brings him joy, only to have his work briefly considered and discarded. And most of the time when this happens, the real reason behind this is never explicitly told "This is my project and I am in power – firmly kicks the ground" but this is paraphrased with words like "this does not fit the community needs". There are also maintainers who truely are dedicated to the community and if in power only for this greater good with no personal gains. They are sincere. If so why not let the community express itself, for instance through voting, instead of making decisions in its name ? Now let's consider some points for an alternative take on what "code" and it's management could be. - A library is not just a pack of implementations for a given solution (a categoria) it's also the public place on top of which such implementations can be enunciated (an agora). Version tags hint at this reality (code is a Becoming) but we prefer to play it down and hide it in a Changelog because the listed changes are seen as mere incidents on a road that leads to an idealized, objective and optimal state of code in front of which personal preference have almost nothing to say. - To generalize what versions are variants are introduced. A code variant can be defined at any granularity level, small or large and there is ways to state a certain variant must be used, from global to more local scales. - Each user can push variants in its own namespace (e.g: the-lib.public.the-user). - A team of maintainers only curates such variants and its goal is to provide a comprehensive default perspective on the implementation space of the library. A library can have competing team of maintainers. - There is no fork. Either your library is totally different and there is no point in starting it as a fork, or only parts of the library change and this is the wrong variant granularity. Plus a fork is a way to push unwanted changes "out of sight, out of mind", both for the irritated chief maintainer and for the library users that may be interested in what the fork has to offer. - There is no ideal community to please, only a standard/reference set of implementations and multiple variants at multiple scales. Each variant has its own community, i.e. users/projects that use such variants. - Variants are not just code fragments but are places where they can be proposed, discussed, versioned, tested, measured, etc. Want to collect data on the way a function is used in order to bootstrap some machine learning model ? It's the place where this data is stored and can be reached. |