When I file a bug report, I often feel I would like to add a disclaimer, along the lines of:<p>« I'm filing this bug report because I found a bug. This isn't a complaint that the bug exists, or a suggestion that you prioritise fixing it, or a support request asking for workarounds. It's just a report that the bug exists. »<p>But I think actually writing that would come over as rather snotty. Maybe the right thing is to write a post somewhere on what I think is the right attitude for filing bug reports, and discreetly link to it.
I feel like the author is not the best spokesperson considering the overwhelming success he's had with open source on a personal and financial levels. It's like those startup success blog posts.<p>It's also quite idealistic.<p>For other people open source might start as a desire for better software or just a desire to help but then it doesn't play out the same way. The project doesn't have as much success, the effort is high and the positive feedback low, the user demands or costs unreasonable. Then you draw a line and realise you just created yourself a sort of unpaid internship position where the globe is your boss.<p>Having experienced something like this my conclusion is that open source in any continuous form is to be seriously avoided.
> Open source is different<p>I believe the attributes given to open source here are wrong.<p>There is a ton of open source code that is crap where not even the author had any interest in making it actually good (the same is true for writing). There is code that is the result of what's alluded to be "copywriting work" that's open source.<p>For me, this reads like a strawman, or maybe super idealised version, of open source is like compared to a vague strawman of what working in a company is like. It feels like this is neither true nor are those the only options out there.<p>> So if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you.<p>I don't feel the users that are called "abusive" to maintainers and contributers are the ones because some of your code sucks and they want to make it better.<p>It's the ones that want you to pander to their use-case. That have unreasonable demands. But even the ones with bug reports and telling you your code sucks in some way, should have some basic civility while communicating. No power of refusing pull requests shields you from insults and the mental burden of being harassed because you refuse pull requests (or close an issue someone opened).<p>I personally expect other people to value my time, not necessarily in money though. This is a general rule of life, not a matter of open source.
Not my experience with open source at all. I get very few bugs and PRs about actual defects. By and large they are feature requests that are very important to the submitter but not necessarily to me or other users of the project. And they do not care about quality at all - they only care about solving their own problem as expediently as possible and don't care if they introduce new bugs, break compatibility with existing users, or reduce maintainability of the code.<p>As for paid vs unpaid work - I care about quality in both cases. But I'm much more motivated to care about someone else's use case if I'm being paid.
> and not when doing copyrighting work for a well known company<p>copywriting<p>> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money. You are doing work for free, they are risking their asses deploying what you wrote, you both care about quality.<p>In the end the fact you're there making time for any interaction requires some money to be entering the system somewhere, to pay the rent. If the guys deploying it have skin the game and you don't, your helping out encourages the dynamic that FOSS author time is worth less than paid dev time, that rather than send patches just complain and let the little people take care of those details. For free.
Open source authors are annoyed, in descending order, by:<p><pre><code> 1) False bug reports, reporter has an attitude.
2) Minor bugs, reporter has an attitude.
3) Major bugs, reporter has an attitude.
4) Unresearched bugs.
</code></pre>
It all depends on how you report it. The current opinion, largely [1] pushed by people who do little programming but take over OSS projects, that bug reporters are oppressed by the bad, bad high performing developers is misguided.<p>It leads to the same dynamics as Mao's cultural revolution, which was not really a success.<p>[1] Not in this case of course.
I keep seeing these kind of threads popping up here on hacker news, where people are lamenting the pains and sufferings of open source maintainers.<p>I agree about the base problem: open source maintainers do lots of work and they are not getting paid. Sometimes people come to expect them to work for them for free! What entitlement, huh?<p>And this lack of concrete reward makes it easy to burn out unless you really care about what you do.<p>This is a real problem. Sure.<p>But here on Hacker news lately I’ve gotten the impression that everyone expects every open source maintainer to be burned out and suffering, and that we should always act as if they are.<p>People should tiptoe around and be afraid to interact, lest they <i>disturb</i> this poor and over-worked maintainer!<p>Needless to say, I think that’s wrong. Open-source thrives on positivity, on energy and a willingness to contribute.<p>We shouldn’t make people who wants to contribute afraid to do so, simply because <i>some</i> maintainers are burnt out.<p>I’d rather say the opposite: if you as a maintainer no longer see joy in what you do, you should step aside or at least take a break. We don’t need you as a force taking energy <i>away</i> from open-source.<p>We’re thankful for what you’ve contributed in the past, no doubt. But your legacy will probably do better if you let someone else carry the flame from now on, or at least for a while.<p>There’s no shame in taking a break.<p>Disclaimer: open-source enthusiast, contributor and maintainer.
There's many motivations and circumstances behind the maintainers of open-source projects, and I think this post works off a too simplified & idealized perspective on that. It seems to mostly assume that an open-source project exists because the maintainer wants to make the software the best it can be and is free to do so because they got a nice income from something else and no big challenges prioritizing it against other things in their life.
I noticed a missing feature in an OSS product I use. I pointed out the general mechanism of how it might be implemented. 3 hours later it was implemented, and the maintainer thanked me.<p>I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"
I think most people forget that when you (or anyone) puts something out there in the public domain, there is <i>no obligation / entitlement</i> on either sides.<p>The user is not obliged to make a payment to the creator, nor is the creator obliged to respond to every need (question/bug report/contribution)<p>Any warranty or service request must come with some form of contract between the user and creator.<p>We as a community must help in people understand this. Open source is not a contract. No one is entitled to anything.
> Open source is different, it's an artifact, it's a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding.<p><i>Open Source</i> does not always mean <i>hobby project</i>. Plenty of people make a living writing Linux kernel code, for instance.<p><i>edit:</i> ketzu beat me to it.
Some context for readers: This is Antirez, the creator of Redis. Dude's insanely smart (saying this not yet having read the article).<p>EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.
Not all open-source is created equal. There are many open-source projects where all the key contributors are employed by a big corporation. And their performance review depends on the work they do on the open source project. like Go language, AOSP, Chromium, VSCode, dotnet, Zstd. Most Linux contributors are also doing what their employers tell them to do.
> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money.<p>If an open-source project grows to the point where time is insufficient to maintain it alongside your day-to-day job, then the matter of money becomes inevitable. And I'm not talking about allocating one's entire free time to the project, but just the time one assesses to be reasonable for this hobby, which can be rather short because of other occupations (rest, family, other hobbies, etc).
><i>Open source is different, it’s an artifact, it’s a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding. And you want it to rock, to be perfect, and you can’t sleep at night if there is a fucking heisenbug.</i><p>Not necessarily. For paid contributors (often among the most important ones in "open source" projects with corporate involvement) it can be just another job. And for casual open source creators, it can be just a small hobby, not some obsession with it being perfect. Heck, a big number of open source codebases are left to rot as soon as the dev moves to something more shiny...<p>So when he says "if a user of your software is addressing you because some part of your code sucks, and is willing to work with you to do something about it, and is very demanding, don’t think they are abusing you because they are not paying you. It’s not about money. You can ignore bugs if you want, and ignore their complains, you can do that since you don’t have a contract to do otherwise, but they are helping you, they care about the same thing you care: your software quality, grandiosity, perfection." that might be true for Redis, or Sqlite etc, but not for all FOSS projects, including many otherwise succesful ones...
<i>> Open source is different, it’s an artifact, it’s a transposition in code of what you really want to do, of what you feel software should be, or just of all your fun and joy, or even anger you are feeling while coding. And you want it to rock, to be perfect, and you can’t sleep at night if there is a fucking heisenbug.</i><p>This has been my experience.<p>I have refined my development skills, as a <i>direct</i> result of my OSS work (I've been writing open-source for over twenty years). During this time, I was a manager, at my "day job," and the company I worked for actively discouraged managers from being engineers. I wasn't having that, so I did OSS on the side, to keep my chops up.<p>Also, I worked for a company that insisted on a rigid, waterfall-based development methodology, that I thought resulted in sub-par software. It worked great on hardware; not so great on software.<p>Through my OSS work, I was able to prototype and refine a methodology that is a great deal more flexible than that used by my corporation. I feel that it results in far better software.<p>I have not experienced a whole lot of the troubles that Antirez encounters; mostly because I haven't authored anything of the scale of Redis. I have, however, authored another project that has become a worldwide standard framework (for a much smaller demographic), and the best thing that I did for it (and for myself), was to get the hell away from it. It's being maintained by a team of fairly brilliant and energetic folks that have taken it to the next level.<p>I really feel that if I had remained "in the mix," I would have stunted it.<p>As Twain once put it: <i>"I cannot help but notice that there is no problem between us that cannot be solved by your departure."</i>
> they care about the same thing you care: your software quality, grandiosity, perfection.<p>Nope, I don't care about this at all.<p>I don't like writing software in of itself. I like trying to find eutectic points of different molecules in software because it cheaper than doing it in a lab, I like being able to explore whats running on my router because I'd like to know what security holes could lie there. I like c and c++ because its way faster at run time and uses less way resources when trying to find low dimensional space projections of energy matrices than doing it in python. The code itself? I don't care about it at all to the extent that I can get what I want from it.<p>Not everyone who writes open source software cares about the same thing, but its good that the author found something they like to do as with I.
Generalizing a complex concept is never easy and in doing so we often make mistakes. This happens also in this post.
At the same time, finding counterexamples is easy and it is even easier when the matter is related to personal motivation or choices.<p>At the same time, I greatly resonate with this need of quality and this brings to my mind this book [<a href="https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance" rel="nofollow">https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...</a>]. In an environment obsessed with growth (more customers, more downloads, etc.) it is often difficult to make long-term choices which gives to quality the right level of importance.
I don't think "most" people produce their best work while working on something in their spare time. That simply doesn't make sense. Your work is something you're paid to care about and do well with all your attention, while most open-source projects are like hobbies that you practice semi-randomly in your spare time. For every open source project that's polished and well-tested and well-maintained there are 1000 which are hastily written, simply without any tests, abandoned, etc.<p>I don't doubt there are people who put their soul into fantastic open-source projects instead of any code at their work. But then it's a question why they're still in their day job in the first place, if they don't like the job or don't want to care about their job. Sooner or later the best course of action would be to quit and either work on their own project full-time and try to monetize it, or find a job they're actually passionate about or at least OK with caring about. I understand that the author himself made redis big, but then it also pretty much became his full-time job and I doubt his understanding reflects that of most other developers out there.
Open bug reports, I can't see that as a problem. If it doesn't seem well researched, you can leave it be or ask for better confirmation. Otherwise it helps you write better software.<p>Pull requests and patches are even better. Someone has researched the problem and attempted a solution. You can review that and see how it fits into your bigger picture.<p>There's two little diseases in OSS.<p>1. Loud, bullying complainers who attempt to monopolize the communication channels, spamming mailing lists and chat rooms about their problems and refusing help with workarounds, etc. These people are usually mediocre programmers or non-programmers.<p>2. Apathetic maintainers who may be working on little features they care about and not worrying about the quality of the project as a whole. I remember the experience of patching an upstream project to the one I was working on and I could not, for the life of me, get the upstream project to care that they had a bug that made their software look bad. They were actively maintaining the project but I suppose they weren't focusing on that area. That's a real turn-off to helping them out in the future and leads to forks.
That's so true. I still work and put a lot of energy and work into a project I began to love during my time at the university: <a href="https://github.com/sirixdb/sirix" rel="nofollow">https://github.com/sirixdb/sirix</a><p>I've spent so much of my spare time working on the project with some gaps since 2012 (and before under a different name at the university since 2006 or 2007). Last year during Hacktoberfest I got first contributions and since then at least another guy, Moshe works constantly on clients for Python and TypeScript and a frontend using Svelte: <a href="https://github.com/sirixdb/sirix-svelte-front-end" rel="nofollow">https://github.com/sirixdb/sirix-svelte-front-end</a><p>I've got a lot of great contributions since october last year and it's such a good feeling, despite spending money for the domain <a href="https://sirix.io" rel="nofollow">https://sirix.io</a> and stuff like a logo and so on :-)
In his book "The workmanship of risk", the industrial design philosopher David Pye said that the best work of the century will be done by amateurs. The reason being that a professional's work will always be held back from perfection by the fact that one has to balance the quality of the paid work relative to what one can reasonably charge for the work.
I think that a lot of people here are forgetting that a project is whatever you make a project to be. It does not need to be operated like a bureaucratic profit seeking corporation. The problem is that the corporate world leaks their madness into our private lives. Just do whatever you want and have fun. Remember that you can choose any type of societal model to structure your project. And most importantly you are free to walk away at any time. But there exist two things here the real project and the social avatar of the project and how the people on the project interact with each other. What belongs to whom? and does it matter? Sub specie aeternitatis this whole thing feels like an effing Herzog movie. Please don't let yourselves get carried away by this nonsense. Like whats the effing point here Fitzcarraldo? I mean seriously people, as a humanity, where are we going so fast that we can't wait to get there and why don't get there with joy?
Quote: "As somebody said, the best code is written when you are supposed to do something else."<p>Not for me, my best code is when I write stuff for myself. None of them are open source and they tend to have better code than stuff I work for clients. Which usually means I borrow my code from my pet projects a lot when solving client's problems.<p>That also leads to a nice side effect that over years I have a huge collection of personal code that I just copy/paste and I know it works. When I do a live session of creating a PoC the client even if himself is a developer gets lost in my fast switching of pages, copy/paste, my fast way of talking and throwing overwhelming information at him that in the end they just get lost. And one hour later a final "it's done, here take it" usually gets a "holly shit, that's awesome". When I hear that I know the client is mine.
>don’t do the error of reducing the interaction to a vile matter of money<p>The most important thing I've learned from reading antirez's blog posts is a certain way of thinking about the labor market that I'm guessing is much more common in Italy (and maybe in France and Spain) than where I live (namely, the US).
I sometimes wonder how much of a pain it really is? I've seen a few impolite complaints here and there on GitHub, but not as much as posts like this (or some comments here) imply. Am I missing something? Is it one of those loud minority things or do you fell that OSS disrespect is prevalent?
While I understand some of the sentiment, I disagree with most of the opening. When it comes to the open projects I want to do, often it's either a library that I break off from something I am working on that I actively need. At other times, those projects languish because of a lack of motivation, time or both.<p>Some of my best work comes out of when I'm getting paid to do the work directly. I take some level of craftsmanship/pride in what I do. Those are the things I <i>finish</i> and more than one has seen production use for over a decade. Not everyone has pride in the craft for their paid work, but that's kind of the point, not everyone is the same. I do wish more people took care in their craft though.
> As somebody said, the best code is written when you are supposed to do something else<p>Offer not good for user interfaces. :)<p>At least in the Gnu-slash-linux world it's like this. I once fixed a volume slider widget where the lowest value was <i>almost</i> zero. I can't be sure, but it's quite possible that when I realized the stupidity of that bug I took a break and went back to my regular job.<p>Nearly every open source UI I've ever seen looks as if it were designed as a gift for the in-laws on Christmas eve.<p>The exceptions generally leverage the web (or borrow large parts from it). That's why people are revving their Electron monster trucks in your craggy-ass Gnu-slash-linux parking lot.
"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian.<p>This is missing one important variable -- the age of the project. Sure, if I have to fix a bug at work, in some crufty old software, that I probably didn't write, that's a lot less appealing than writing brand new, clean, perfect code on my own project.<p>On the other hand, if my new project gets to be a few years old, and develops some cruft of its own, and I have to fix a bug in it, that might look a lot less appealing than a brand new work project, in which I am writing new, clean, perfect code.
*YMMV<p>Maybe engineers who have some basic self-guiding work ethic are able to product high quality code also in the job that allows them to put a roof over their head and feed their kids.
The main problem with open source issue reports is so frequently nothing to do with the way something is said (though that is often a problem), but the actual content of what is being said. 90% of the issues I end up with on GitHub aren't requests for support on the project, they are requests for tutoring of basic programming and IT issues.
This reminds me a bit of artists that complain that they can't live from it. IMO OSS is very similar to this, the salary for doing something you like is by definition pleasure or even fulfillment. But you have to play by the rules of the system. Hence my often frustrating consulting work pays for my hobby OSS. Plain ying and yang.
About the quote at the bottom, I see a parallel on how responsibility/obligation can backfire. Very often it removes the initial drive / intrisic motivation which weighs high in the outcome quality.
Just yesterday I was called no less than fascist on GitHub. Because some years ago we have removed an obsolete and insecure authentication method from our opensource app.
>Like a writer will do her best when writing that novel that, maybe, nobody will pay a single cent for<p>No problem, it's just about woman's who write...not the job of writing.
The real underlying issue is<p>a) how to deal with public goods especially networked public goods.<p>b) The production cost vs use cost.<p>c) we act on margin always not on total as my mind may think but our act is temporal.
Anyone who derives dopamine from their work to the point of being willing to obsessively work for free is treating their “work” like a drug and in essence is no different from a drug addict. In this arrangement the users supplying bug reports and extracting value from the author is the drug dealer.<p>This isn’t a healthy arrangement and often leads to burnout and depression. You cannot blindly indulge in your passions. You must apply some level of discipline and long term meaning to what you are doing or you will destroy yourself.