[GorgeRonde]

> This is my project

Ownership is essentially the main problem of OSS here.

> If it stops being fun, I will stop working on it, which will pretty much kill the project.

See what I mean ?

Makes me think of Hickey's "Open source is not about you" rant and I can't prevent myself from hearing "It's about me".

https://news.ycombinator.com/item?id=18538123

[bhaak]

It doesn't need to be about me.

But if it isn't about me, somebody else has to do the project management and the code commits.

That's just the way it is. When OSS goes further than the "my itch to scratch" scenario, it gets complicated and there needs to be a way to motivate people to scratch other people's itches.

[eikenberry]

> Ownership is essentially the main problem of OSS here.

I'm not sure I see the problem. Care to elaborate on just how ownership is a problem for OSS projects?

> Makes me think of Hickey's "Open source is not about you" rant and I can't prevent myself from hearing "It's about me".

Hickey's and the parent's CoC both express that, as far as people go, the OSS project is about the project owner(s) and not about "you" as a user of that project. It seems you are implying that this stance is bad and narcissistic instead of a healthy approach to working with OSS (which seems to be the more general interpretation).

[blihp]

I don't see a problem: any given author / contributor has their own reasons for providing something... and you and I are most likely not one of them. We can choose to tag along for the ride or not. If it is of value and we have issues or need missing features, we can contribute to the project to make it better. For many people, that is often one of the reasons they even bothered to open source it to begin with: to get help.

If one lacks the skills to or time & interest in helping, the two most productive courses of action are either to move along or throw money at the problem. Now maybe your issue is the developer/maintainer themselves. i.e. the project has value but you don't want to deal with the author(s)/maintainer(s). That's fine: fork the project. If enough people feel like you do, the original project will likely die due to these open source 'market' forces. That's a risk any author takes making the project open source to begin with.

I have absolutely no problem with a developer saying 'this is my project' or 'I'm not interested in your problem' as a default answer. It is their project/time and my problem after all. Assuming I don't have the time/skills and really want their help, I can offer to throw money at them and many will develop an interest in solving my problem. If that doesn't work, I can offer to throw money at someone who will.

Note that none of these issues are unique to open source: try to get Apple/Microsoft/Google to fix a longstanding bug or add a feature that you really want or need. Odds are, you don't have the order of magnitude of money to get them to care. And you usually don't have the source either, so you're out of luck.

[nine_k]

It's easy.

It's my project, I will lead it the way I see fit. I decide what gets merged, what issues have priority, what gets you banned.

It's also open source. Fork it if you want, drive your fork's development the way you see fit. Now it's your problem, not mine.

[mikekchar]

When I do eventually write a COC for my project (i.e. when more than 0 people have seen it :-) ), this is an important section that I want to write. I choose free software licenses because I want my users to be as free as I am in their choices.

I thought long and hard about why I write free software. It's not for an altruistic reason. I do it because it is something important to me. If I allow others to dictate what I should be doing, then I lose my reason to write free software. The free software license is their guarantee that no matter what crazy thing I decide to do, or say, they can carry on without me. That's as fair as I want to get.

[sunir]

If only there was a system that aligned user goals with producer goals. Some way that the users can get the product “customized” to their needs through an incentive.

Like it or not, volunteer software is not meant to be about users. If you want it to be about you, you have to pay money.

[GorgeRonde]

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.