This is not a community project. This is my project. I know that will disappoint some people, but I do this for fun in my own spare time. If it stops being fun, I will stop working on it, which will pretty much kill the project. There are millions of projects in the world and the only reason they continue (if they actually do) is because the maintainers stubbornly stick at it.
With that in mind, here is the code of conduct: If it is fun for me then it is good. If it is not fun for me, then it is not good.
Things I find fun include: Bug reports that explain what you saw and what you expected to see. Suggestions for features that would make your life better. Stories of how the software so far has already made your life better. Entertaining stories of how you used the software (bonus points if it includes pictures of cats). Offers to volunteer to improve something (super bonus points if you actually improve it). Questions about how the software works. Offers to write documentation (super, executive class bonus points if you actually write some). Answering questions that other people ask (bonus points if you get the answers right).
Things I don't find fun: Drama. That is all.
To some extent, I will accept drama in exchange for money. But it has to be a lot of money. Think FANG level money. If you don't have FANG level money that you are willing to give me in exchange for drama, just don't do it -- even if you think it is the most important thing in the world.
There is no other code of conduct. I may arbitrarily declare some things fun for me and some things not fun. Please pay attention when I declare one way or the other and act accordingly.
Feel free :-) I warn you that the only way I had the courage to write it was that I drank a considerable amount of nihonshu (Japanese sake). It was pink. The label said that the pink colour was a natural result of the kouji (aspergillus oryzae). I'm skeptical :-)
But, in all seriousness, I've been thinking about it a lot and really the main thing, I think, is for everyone (even the maintainer) to avoid drama. If you find yourself in a dramatic situation that seems to have been caused by your actions, simply apologise for the drama that you have unintentionally invoked. I think that's all that is necessary.
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.
> 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).
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.
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.
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.
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.
Think FANG level money. If you don't have FANG level money that you are willing to give me in exchange for drama, just don't do it -- even if you think it is the most important thing in the world.
The poster is talking about a level of money, not the exact companies. The whole point of the line is that you should feel excluded from bringing drama if you don't have that level of money to give the developer.
#Code of Conduct
This is not a community project. This is my project. I know that will disappoint some people, but I do this for fun in my own spare time. If it stops being fun, I will stop working on it, which will pretty much kill the project. There are millions of projects in the world and the only reason they continue (if they actually do) is because the maintainers stubbornly stick at it.
With that in mind, here is the code of conduct: If it is fun for me then it is good. If it is not fun for me, then it is not good.
Things I find fun include: Bug reports that explain what you saw and what you expected to see. Suggestions for features that would make your life better. Stories of how the software so far has already made your life better. Entertaining stories of how you used the software (bonus points if it includes pictures of cats). Offers to volunteer to improve something (super bonus points if you actually improve it). Questions about how the software works. Offers to write documentation (super, executive class bonus points if you actually write some). Answering questions that other people ask (bonus points if you get the answers right).
Things I don't find fun: Drama. That is all.
To some extent, I will accept drama in exchange for money. But it has to be a lot of money. Think FANG level money. If you don't have FANG level money that you are willing to give me in exchange for drama, just don't do it -- even if you think it is the most important thing in the world.
There is no other code of conduct. I may arbitrarily declare some things fun for me and some things not fun. Please pay attention when I declare one way or the other and act accordingly.
Thank you.