Live data from Hacker News

On Being a Free Software Maintainer

feaneron.com

101–110 of 147 posts

Re: On Being a Free Software Maintainer

#101
post #100

These "problems" are not specific to open source projects: Whenever you provide a service of some kind, very few people will thank you, most will just use it and another very few will be very vocal about where, how and why you are an incompetent idiot who is just waiting for their advice. But the "problem" really does lie with you if you cannot tell people they got what they paid for (in case of pro bono work, like F…

I organise the yearly family Christmas gathering back in our village whenever I am in my home country. The deal is that every working adult is supposed to contribute a few dollars towards food and drinks. It really isn't much money. Everyone is supposed to chip in, in whatever way they are comfortable. No one is paid to attend and no one is forced to attend.

Back to your sentiments, the amount of nonsense I have to put up with from some family members is unbelievable. Luckily there are some good family members who usually step in and put them in their place. So yes people are a problem, even our own family members give us problems. I still organise get together and ignore the naysayers.

Re: On Being a Free Software Maintainer

#102
post #73

Earlier quoted context omitted.

> 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 re…

Who told you that? The word "open" is one of the most overused words in American marketing, and has never been an implicit grant of rights to anyone. People were routinely banned from project mailing lists long before codes of conduct became common, and corporate projects labeled "open" were often completely closed.

I think that require to leave legally refers to situation where that person comes back again and again and again. So that you may use your lawyer to threaten him or his layer.

Re: On Being a Free Software Maintainer

#103
post #87

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…

I don't understand the downvotes for this. I feel that by making something public and open source, there is an implicit assumption (unless otherwise stated) that the software is worth sharing. The problem is that this puts what I consider the right amount of responsibility squarely in the middle of a continuum: library authors shouldn't be totally free of obligations to others, but the insane abuse that people level…

This rule accepted in general would mean that all students who put their homework on github are doing something wrong.

Or that all professionals who just play around technology or mini projects are required to keep them secret until they are totally sure they will maintain it forever.

That is just not workable and overly limited.

While owner can not expect gratitude, the "I’ll work on this when I want, however much I want, and you should just take it or leave it" is absolutely fine and should be fine. Just because it exists on the internet does not entitle the rest of the world to anything.

Re: On Being a Free Software Maintainer

#104

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…

So the article writer became "maintainer" by virtue of being something like "the only person that currently cares". Should they have rejected access to the code and ceased contributions at that point, to not be irresponsible years later?

Re: On Being a Free Software Maintainer

#105

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…

This really shouldn't be downvoted, as it is a valid stance (one I don't share, BTW, or not much).

Human social instincts strongly push toward this position, informed (largely) by metaphors and similies rooted in excludable goods even when nonrivalrous (eg. the prototypical Commons).

Software, though - and most especially Free Software - is part of another realm entirely, or at least verges on it: Things that largely grow, proliferate, and spread themselves, even if they do it through coopting human agency. Examples are stories, families, communities, ideologies, movements, hobbies, cultures, and most importantly, individual humans themselves.

"If you save a life you become responsible for it" is one of the few succinct ways this has been expressed, which of course doesn't do much to delineate the obligation or its limits. But the sentiment is clear.

To what extent can an author (of fiction or non-fiction) disclaim responsibility for their work if it takes on a quasi-life of its own? An artist for a work that is misappropriated?

How difficult is it to disavow a family that you have broken with? An embarrassing ancestor who accumulated the family fortune through unsavory means? A child that has grown to become a notorious public enemy?

Can a founder of a movement disavow its extremist fringes?

Does a celebrity actually have any responsibility at all toward their fans?

How difficult is it (or should it be) for a hobbyist to avoid being associated with those who share their hobby, but who also make the hobby unwelcoming to the Other?

By now you must have a dozen objections to this post, of all the ways writing software is not like these things I've mentioned, but there is also something deeply similar, though it is difficult to articulate exactly what that is.

An author of software, and more precisely a maintainer of software, is responsible in some sense for the nebulous thing that the group of people that software draws together is, even while also being a member of that same group.

That the responsibility does not necessarily create much of an attendant obligation is not necessarily clear, when so many social customs are predicated on such obligations being implicit (at least).

Even less clear is the extent to which such obligations, when voluntarily assumed, can then be discarded.

An analogy may be helpful here:

Having moved to a new city, and subsequent to joining some existing social group or club, you volunteered to take care of some aspect of a shared recreation (to bring the salad for a weekend picnic, for example), but you then discover that there are additional logistical and even financial costs involved that you didn't anticipate (the picnic starts much earlier than you're used to, the group includes many vegetarians and vegans who are used to having an extensive variety of salads at such occasions, etc.).

So, having voluntarily assumed this obligation, but not having given what could be objectively called fully informed consent, to what extent are you still responsible for addressing the expectations of this group (as a group, and also as individuals) you're now disappointing?

And how do the analogous obligations change (and grow) when you are (effectively) the founder of the group?

This morass of interpersonal relationships is the sort of thing that being a software maintainer requires navigating, and the situation isn't made simpler just because the central artefact the group revolves around is some non-excludable, non-rivalrous software that is being created and maintained, especially when the name attached to the software is just such a rivalrous good.

Disavowal of otherwise implicit responsibilities and obligations is something that seems to crop up more often in recent decades than previously, from IANAL and TINLA (or even IAAL, But Not Your Lawyer), to the increasingly commonplace "I Do Not Speak For My Employer".

Such disavowals being (apparently) necessary, authoring and maintaining software clearly also strongly implies at least some responsibilities and obligations, at least as a great many humans perceive things, and it is worth discussing just what those are, as well as when and how to effectively disavow them when not appropriate.

As I said at the outset, I personally feel the set of those obligations is smaller than the parent post states (neither software nor the community that forms around it is something that you are obliged to actively nurture), but my disagreement doesn't imply a downvote. It is a valid contribution to the debate on this topic.

Re: On Being a Free Software Maintainer

#106

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

> 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).

Re: On Being a Free Software Maintainer

#107

Earlier quoted context omitted.

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…

>Make it easy for people to pay you. There's definitely a startup opportunity for this - making it super easy to receive payment as an OSS developer (either as a business or sole developer) and making it easy for businesses to pay. If I saw a new issue on github and it came from a corporate "OSS gold account member" which potentially comes with $$$ attached I'd be much more inclined to implement it. As it is my motiv…

"Daniel Pink's new book, Drive, in which he highlights the rather stunning amount of counterintuitive research that suggests that money can actually make people less motivated to do creative works."

https://www.techdirt.com/articles/20100603/0311539672.shtml

Re: On Being a Free Software Maintainer

#108
> It means you are trusted. It means you are trustworthy. It means you are skilled enough.

It means those things to the org that made you the maintainer. It means nothing in particular to the users, bug reporters, and people who offer up fixes and features who don't already know you.

> If you are open to review other people’s contributions, there is a high change you will find challengers disguised as contributors.

New devs making a first-time pull request typically do not yet trust a project's dev process. They also realize that the project has no way to trust their own skillset. To break the stalemate the new dev typically "oversells" their patch set and errs on the side of TMI to the point of being defensive.

Doesn't it fall to the maintainer to keep things positive, clear, and on-topic in such situations? If the org takes that as a necessary skill of a maintainer and mentors to it, it's at least possible to have a decent experience as a maintainer. If not, then I speculate any maintainer would interpret those skills as out of scope for project maintenance.

I also speculate they'll interpret each "challenge" as a distraction from their duties and steadily progress toward an increasing likelihood of burnout.

Re: On Being a Free Software Maintainer

#109

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…

I think I understand you completely, but I also think I know why you were downvoted. The problem is the implied promise of having a software project page on something like GitHub with descriptions, documentation, etc. This, in my mind, and probably yours too, implies a promise of future development, maintenance or at least security bug fixes. When such things are not forthcoming in a manner one might reasonably expect, we feel as though we have been cheated out of something we (rightly or wrongly) feel was promised to us.

Maybe what would be useful would be some standard (and required!) marking for all software projects on what the current level of maintenance is. Is it

Level 0. I wrote this in an afternoon and have no plans to ever look at it again — use at your own risk.

all through

Level X. This project is under active development and also has maintainers for a stable branch, which also receives security bug fixes in a timely manner.

In short, what I think is actually irresponsible is for projects to look like they are close to level X but then have maintainers behave like they are at a much lower level, and who think that any level of behavior is OK since they don't get paid and haven't personally promised anything. It would be better for all involved if the expected (approximate, of course) level of maintenance could be explicitly announced – this might make it clear to users what level they can expect, and make it clear to maintainers what level of involvment is expected of them to be able to call themselves “maintainers”.

Re: On Being a Free Software Maintainer

#110
post #104

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…

So the article writer became "maintainer" by virtue of being something like "the only person that currently cares". Should they have rejected access to the code and ceased contributions at that point, to not be irresponsible years later?

They might have taken over the role of maintainer, but if the level of involvment which the project required was too much for them, it would have been their duty as maintainer to declare the project moribund until a more active maintainer could be found. To keep the project active and looking alive is to mislead users and implicitly promise a level of support and development which they know they cannot uphold.
Post reply on HN