Live data from Hacker News

On Being a Free Software Maintainer

feaneron.com

51–60 of 147 posts

Re: On Being a Free Software Maintainer

#51

The way I have learned to deal with it is switching to a mostly read-only software publishing. The default of my answers to issues is some sort of "No", which might be "good idea, but not now", "good, but not planned, PR open", "not within the project's objectives", "bad idea, there's a better way", etc. This is not great, I'd love to be able to do OSS fulltime and help hundreds of people out there. But the reality i…

What’s your project?

I am running a fairly popular Ruby gem. Donations are indeed very low. To the point I have just remove the link.

Re: On Being a Free Software Maintainer

#52

This has been discussed before and it has been true for me as well. I don't have a large, super-popular package I maintain, but several lesser known ones, some of which I wrote, and several of which I just adopted and passively became a maintainer over time. At some point the pressure from the community made me pass the magical threshold between fun/useful/rewarding and downright chore. It has permanently changed my…

> useless code of conduct #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 i…

> 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

Re: On Being a Free Software Maintainer

#53

What is the latest, state of the art way to earn money this way ?

Completely not proven yet, but I'm convinced: ask for it. Make it easy for people to pay you. Find a way (and reason) for people to invoice you for payment. Tell people that you expect payment even if they don't legally have to pay. Make it part of the "community ethos" that payment is a natural and good part of working with the community. Free as in freedom, not beer. Ask for beer and give freedom in return. I have…

Open source projects are good at convincing their users (other developers) that they provide value, but developers are not yet very good at advocating for that value up the chain. I think the key to developer-driven enterprise SaaS is teaching developers to advocate for the value of their tools. Other departments do it very effectively, and it has the beneficial side effect of raising the employee’s status in the organization.

Re: On Being a Free Software Maintainer

#54
I use a lot of open source packages, and I’m immensely grateful to anyone who maintains one.

I also want to mention that I donate whenever the option is available.

However, here is my personal opinion that will most likely get downvoted to oblivion: if you are putting a tool out there for others to use (not just software but any tool), then you are responsible for its wellbeing and maintenance, regardless of whether you charge money for it.

In my opinion, it is irresponsible to release something, anything, and then abandon it.

If you don’t want to be responsible for it, for example if it’s a hobby project or something, keep the repo private. If you release it with the intention of maintaining it, and your circumstances change later, do your best to find another maintainer.

If you want to charge money for it, do that.

But if your attitude is gonna be “I’ll work on this when I want, however much I want, and you should just be grateful for what you get and deal with it” then, well, that’s where my sympathy and respect for you ends.

Re: On Being a Free Software Maintainer

#55

Earlier quoted context omitted.

> useless code of conduct #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 i…

# Code of Conduct This is a dictatorship, I do what I want. Thanks.

This is my .git, there are many like it, but this one is mine.

Re: On Being a Free Software Maintainer

#56

The way I have learned to deal with it is switching to a mostly read-only software publishing. The default of my answers to issues is some sort of "No", which might be "good idea, but not now", "good, but not planned, PR open", "not within the project's objectives", "bad idea, there's a better way", etc. This is not great, I'd love to be able to do OSS fulltime and help hundreds of people out there. But the reality i…

> I consider this project feature complete. If you want a new feature, you need to bring a compelling reason to convince me and a good patch.

Re: On Being a Free Software Maintainer

#57

Earlier quoted context omitted.

> useless code of conduct #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 i…

> 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

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.

Re: On Being a Free Software Maintainer

#58
post #32

Earlier quoted context omitted.

Are you OK with other people using this ? This looks to be the perfect #Code of Conduct

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…

You just got another project to maintain. :)

Re: On Being a Free Software Maintainer

#59

This has been discussed before and it has been true for me as well. I don't have a large, super-popular package I maintain, but several lesser known ones, some of which I wrote, and several of which I just adopted and passively became a maintainer over time. At some point the pressure from the community made me pass the magical threshold between fun/useful/rewarding and downright chore. It has permanently changed my…

> useless code of conduct

# Code of Conduct

in the United States, the development of the Code of Conduct appears to be a mechanism, refined by lawyers, to make a legal case to -> kick someone out The code of conduct uses words to describe desired outcomes of cooperation, but actually, it defines boundaries such that there is a specific reason to require a person with some behavior pattern, to leave, be blocked and removed from the project.

Legally, if the project is declared 'open' then there was no way to require someone to leave, legally. IANAL

Re: On Being a Free Software Maintainer

#60
post #2

This has not been my experience. I maintain various popular and not-so-popular projects (although maybe not to the level of gnome calendar) and I just work as much as I want. If I don't feel like handling an issue right then, I say I won't have time soon and that PRs are appreciated. The vast majority of people are understanding, I don't remember anyone making a fuss about it.

Maybe because the consumers of your work are developers? GNOME Calendar (the OP's project) is an app for end users.

Developers tend to be worse in my experience. I picked up maintaining a few projects awhile back (django-haystack, pysolr) which are in that unfortunate position of having been popular enough to get used a lot but never getting much corporate support. The issue trackers regularly get requests which are important to someone’s business but not enough to actually do any work. Sometimes that gets as far as a pull request but that much less commonly gets to the point of passing tests or support for more of the support matrix than they need, although that often doesn’t rule out requests to just merge it anyway.
Post reply on HN