20 ms·

The open source paradox

368 points by stargrave 6y ago

SZJX 6y ago
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. 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.
outsomnia 6y ago
> and not when doing copyrighting work for a well known company copywriting > 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. 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.
- antirez 6y ago
  Signaling bugs is as much work as it is to send a patch. Sometimes is even better work. For instance a bug report that is the fruit of a deep investigation is worth a lot more than a weak patch that is fixing the problem in the wrong way, often because of lack of understanding of the system. I don't agree there is a clear distinction of patches and bug reports in which one is work donated to the project and the other is not. Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
  - outsomnia 6y ago
    > Signaling bugs is as much work as it is to send a patch. No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable. Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
    - rbarrois 6y ago
      It depend on the actual patch, and bug report. I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working. And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself. Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals. In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
      - outsomnia 6y ago
        It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer. Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
        jka 6y ago
        Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations. If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable. A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug. All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
- MaxBarraclough 6y ago
  At the risk of mirroring antirez's response, and on top of that I suspect I might be misreading you, but still: > 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. A good bug-report isn't merely whining, it's a contribution to the quality of the project. It takes some amount of time and effort to file a decent bug-report, and it helps the project better achieve its goal. It's less valuable than a good quality pull-request to fix the issue, but it still counts. (The same is true of good quality feature-requests, but to a much lesser extent in my view.) That's different from someone having a sense of entitlement. Unless you're on their payroll, you aren't obliged to prioritise their bug. More generally, you aren't obliged to continue your involvement in the project in any way.
- sidlls 6y ago
  I've come to view OSS as the software industry's inferior analog to waiting tables in the movie business. It's inferior because at least waiters are paid for their labor. The OSS authors who are successful are also paid, of course: but at that point they've "made it" and no longer have the same concerns (e.g. paying bills) that the 99.999% of other OSS developers have.
  - 0SSawayyyy 6y ago
    That's an interesting take; I view OSS as an act of generosity. It's a gift given by the author, without any expectation of reward. Waiting tables in the movie business feels more like a hustle; people do it so they can live in LA or Vancouver while they seek fame and fortune. I have seen a trend of fame/fortune-seeking in OSS recently, but it seems more like a toxic offshoot than the norm. The best OSS projects are still made by people who are genuinely trying to share solutions to common problems. Maybe they "make it" financially, but that is orthogonal to OSS contribution.
the-dude 6y ago
What is the paradox? I don't see it.
- antirez 6y ago
  That the OSS writer cares and is often willing to fix code she writes for free, more than the other paid work she does.
  - the-dude 6y ago
    Ok, I do see that. Somehow the title does not work for me, but that is o.k. I guess. To get back to your point, I like to call it 'play' ( vs work ).
    - antirez 6y ago
      Yep, the title is not a perfect match with the text indeed. I documented our interaction in the post.
- mr_toad 6y ago
  In economics it’s known as the subscription equilibrium.
ketzu 6y ago
> Open source is different I believe the attributes given to open source here are wrong. 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. 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. > 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. 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. 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). 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.
- franciscop 6y ago
  > There is a ton of open source code that is crap The good thing of open source is that people pick the best available, or at least some that is "good enough" when there are many choices. The bad thing of proprietary code is that you paid for that, so you are stuck with it. Throwing it again and redoing it has a high cost, staying with it has a (high?) cost. But if you want custom code or very specific code, it's going to be one-off. So yes, in general you can say that open source has better quality, because the best rise to the top, while in proprietary code it is what it is.
  - ketzu 6y ago
    I believe that you could easily turn around the argument: To stay relevant with paid software you have to make something people will be willing to buy. If you produce bad software, people will not or at least stop buying it. You can dump everything into the open source domain without any restrictions. Therefore, commercial code is of better quality. It's not that I believe this, I find neither of those convincing. There is great open source software and there is great commercial software. There is a huge amount of bad software on both seids either. Is good open source software better than good proprietary software? Depends on what are the criteria for good, but I don't think that's something we could state as general as "open source is better." Going back to the original article: The distinction the article talks about seems to be personal motivation to make the code better. While there might be a shift to be more engaged in a personal project (which is likely) the licensing model of that personal project is fairly irrelevant for this. Futher, quite a lot of people are also engaged in their job and care about the product they are working on. Are people that don't care about it on their job more or less likely to even start personal projects? To contribute to open source? I don't know, maybe there is some data on that.
junon 6y ago
Some context for readers: This is Antirez, the creator of Redis. Dude's insanely smart (saying this not yet having read the article). EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.
- antirez 6y ago
  NP and thanks for the nice words.
- JorgeGT 6y ago
  And the creator of dump1090! When I was a student receiving Mode-S transponder was so expensive, we had a shared receiver/decoder for the whole eng. school. Now that I lecture there I show the students a $6 RTL-SDR with dump1090 to show how far open tech goes, plus some MATLAB code to store/plot the aircraft data: https://github.com/JorgeGT/PlotRTL1090 https://github.com/JorgeGT/PlotRTL1090
MaxBarraclough 6y ago
> 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. Open Source does not always mean hobby project. Plenty of people make a living writing Linux kernel code, for instance. edit: ketzu beat me to it.
- pjmlp 6y ago
  When employed by big companies to do so, because their main business is selling something else unrelated to the software itself. Doing open source where software is actually the real product usually ends up in hobby project level as donations, consulting or books aren't enough to keep the ball rolling.
- srtjstjsj 6y ago
  antirez himself made his living writing open source code for redis, until July 2020.
mjw1007 6y ago
When I file a bug report, I often feel I would like to add a disclaimer, along the lines of: « 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. » 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.
- tenkabuto 6y ago
  That's an interesting distinction. It's like simply documenting that a bug exists versus arguing that a bug exists and should be resolved. The latter feels similar to making a feature request, which can also be done in Issue trackers like GitHub Issues. Maybe the fact that both the former and the latter are allowed/encouraged to exist within the same tracking systems somewhat contributes to the confusion/conflation of the former with the latter.
- kzrdude 6y ago
  If you would mean it, I think it's nice to instead sign off the bug report with something like this "X is great, and thanks a lot for developing it" - when you're reporting something to a project where you are not previously known.
- FartyMcFarter 6y ago
  Is this really necessary? If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed? If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.
  - pydry 6y ago
    I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected). Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it. I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs. Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
cinquemb 6y ago
> they care about the same thing you care: your software quality, grandiosity, perfection. Nope, I don't care about this at all. 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. 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.
- ricardobeat 6y ago
  You haven't realized you're actually agreeing with him. If someone sends a bug report to your router firmware project, what do they really care about?
  - cinquemb 6y ago
    I wont care (unless im curious enough to explore it), if they want to write a fix themselves they can do it. And if they write a fix, I wont care about it's quality, perfection or grandiosity… and I won't assume that they do either. I don't agree because I'm not making an assumption for others motivations of writing software (or submitting bug reports), nor do I want to. If you and the author want to assume that these are the only motivations can exist in open source software, then that's on you both, I don't have to assume such things.
    - srtjstjsj 6y ago
      Perfection and grandiosity are a thing apart, but certainly you care about quality... Otherwise you'd play video games with fake chemistry instead of study real chemistry, no?
      - cinquemb 6y ago
Dean-DAGsHub 6y ago
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?
- detaro 6y ago
  It's both a loud minority thing (that's still quite draining to be exposed to) and very unevenly distributed between projects/maintainers. E.g. projects aiming at non-/not-so-technical users often have problems with it, especially if they at the same time are in areas where regular breakage is to be expected (e.g. software to scrape/download from popular websites, 3D printing tools would be my guess for good examples). Some projects with corporate users but no corporate backing can run into the same. But at the same time for other projects it might never happen.
mcint 6y ago
Once we’re fed, we can contribute to the gift economy, and homestead our own place in the gnoosphere.
- jlokier 6y ago
  +1 for "gnoosphere". May it be named word of the year one of these years :-)
bboreham 6y ago
Maybe we need to distinguish “altruistic open source” from “corporate open source”?
- antirez 6y ago
  Yes, we need. I call it "indie OSS" vs "Company OSS".
  - jka 6y ago
    There are probably some parallels here with music; some people produce (and may collaborate on) music for pure enjoyment and the craft, and at the same time there are large businesses that have industrialized music creation.
  - eternalban 6y ago
    GPL contra the rest of OSS licenses seems to map to this divide fairly well, don't you think? My impression is that Corporate legal seems to not like GPL, at all. So next one, make it GPL.
fierarul 6y ago
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. It's also quite idealistic. 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. Having experienced something like this my conclusion is that open source in any continuous form is to be seriously avoided.
- acdha 6y ago
  I’ve had similar experiences but haven’t drawn the same conclusion. I haven’t given up on being able to change the norm where a lot of open source users act like they have an enterprise support plan while actually contributing nothing.
  - fierarul 6y ago
    Funny thing: I had my email on a commercial support page for, you know, companies that wanted to pay money for custom work. 100% of the emails were from companies asking various questions; everybody took that page as priority free support for companies. I just removed my email in the end.
    - acdha 6y ago
      That’s a really common behavior. I’ve had people open issues stating that something is a production blocker but of course they can’t contribute time to fix it.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- 6y ago
detaro 6y ago
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.
- ricardobeat 6y ago
  Well, that used to be the case for the majority of OSS. Even when funded by enterprise, the main reason to publish code has always been to share and advance a field, not to make more money out of it.
bobmalone123 6y ago
OP could drop virtue signaling by stopping to write in 3rd “female” person (“she writes software”). Statistics talk.
agumonkey 6y ago
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.
nakedrobot2 6y ago
*YMMV 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.
nvlanders 6y ago
Open source authors are annoyed, in descending order, by: 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. 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. It leads to the same dynamics as Mao's cultural revolution, which was not really a success. [1] Not in this case of course.
- ricardobeat 6y ago
  > mostly by people who do little programming but take over OSS projects You're voiding your whole argument by disqualifying any opposition like that. Anyone disagreeing with you will now fall into that bucket, and give you a reason to ignore them. Can we save that for politics please?
- l0b0 6y ago
  Some open source authors are also annoyed by: 5) Reporters not spending hours getting familiar with the build system to verify the bug in origin/master, even though it's been there in the three last stable releases. 6) Not providing a patch. 7) Not using the appropriate jargon for everything. Entitlement is very much a thing (on both sides of the fence), but these are going to be extremely off-putting for anyone who is only ever going to be an end user.
  - sidlls 6y ago
    Maybe those OSS authors ought to document their software better. A pithy README.md with a toy example nobody would ever actually learn anything from isn't documentation. Maintaining a proper changelog with links to relevant issues/tickets isn't that hard, but it's rarely employed.
projektfu 6y ago
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. 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. There's two little diseases in OSS. 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. 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.
NewEntryHN 6y ago
> 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. 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).
- logicOnly 6y ago
  This makes me think I should take emails/comments less important. These are not customers, they are fans. If it's my project,I should just enjoy it for myself. While it sounds great to personally respond and research what people tell me, it's a major distraction and time waste when I could be doing research.
lichtenberger 6y ago
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: https://github.com/sirixdb/sirix https://github.com/sirixdb/sirix 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: https://github.com/sirixdb/sirix-svelte-front-end https://github.com/sirixdb/sirix-svelte-front-end 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 https://sirix.io https://sirix.io and stuff like a logo and so on :-)
josteink 6y ago
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. 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? And this lack of concrete reward makes it easy to burn out unless you really care about what you do. This is a real problem. Sure. 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. People should tiptoe around and be afraid to interact, lest they disturb this poor and over-worked maintainer! Needless to say, I think that’s wrong. Open-source thrives on positivity, on energy and a willingness to contribute. We shouldn’t make people who wants to contribute afraid to do so, simply because some maintainers are burnt out. 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 away from open-source. 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. There’s no shame in taking a break. Disclaimer: open-source enthusiast, contributor and maintainer.
- xfred 6y ago
  It isn't that easy. If your project is very high quality and you let others take over, you'll be forgotten in a couple of years and others take the credit. Often without doing much except responding to rude bug reports like a trained hotel receptionist. But that is frequently the real goal of those who drive out high performers.
- jlokier 6y ago
  > if you let someone else carry the flame from now on Ha! For a lot of open source maintainers and projects, that's not an option because there isn't someone else. A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that. It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on. Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't. It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all. That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself". That's not maintainers being unwilling to step aside. There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features. Or more reasonably, which just clash with the design direction of the project. The same happens in the real world (non-computer) non-profit volunteer projects. A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.
rushabh 6y ago
I think most people forget that when you (or anyone) puts something out there in the public domain, there is no obligation / entitlement on either sides. 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) Any warranty or service request must come with some form of contract between the user and creator. We as a community must help in people understand this. Open source is not a contract. No one is entitled to anything.
ChrisMarshallNY 6y ago
> 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. This has been my experience. I have refined my development skills, as a direct 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. 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. 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. 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. I really feel that if I had remained "in the mix," I would have stunted it. As Twain once put it: "I cannot help but notice that there is no problem between us that cannot be solved by your departure."
moron4hire 6y ago
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.
agwa 6y ago
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. 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.
deleted 6y ago
[deleted]
jancsika 6y ago
> As somebody said, the best code is written when you are supposed to do something else Offer not good for user interfaces. :) At least in the Gnu-slash-linux world it's like this. I once fixed a volume slider widget where the lowest value was almost 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. 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. 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.
- srtjstjsj 6y ago
  Please don't post flamebait here.
- a1369209993 6y ago
  > > As somebody said, the best code is written when you are supposed to do something else > Offer not good for user interfaces. :) Actually, it's still the best; it's just that that's a very, very low bar, since the competition is actively user-hostile, and looks like it was designed in Photoshop by a graphic designer who never wrote a line of code in their life (often because it was).
unnouinceput 6y ago
Quote: "As somebody said, the best code is written when you are supposed to do something else." 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. 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.
Ironlikebike 6y ago
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.
- srtjstjsj 6y ago
  The amateur's work held back by what one can reasonably spend without funding.
LockAndLol 6y ago
The HTTPS cert for this website points to redis.io . Don't know what's up with that...
- saagarjha 6y ago
  The author wrote Redis.
aidenn0 6y ago
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. I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"
- boulos 6y ago
  Because you kind of did Product Management for them! “Hey, there’s this idea. I have at least one customer [me]. I think it’d be pretty easy to implement like this.” It’s pretty rewarding to have a blueprint for “oh, I can deliver some value, easily”. Got any more suggestions for them? :).
- john_moscow 6y ago
  That's because your wish happened to align well with the maintainer's understanding on how they want to spend their time. Think of it as hitchhiking, if you're both going the same way, it's a win-win: a free ride for you and a free chat for them. But if they need to take a 100-mile detour to get where you're headed, it makes full sense for them to simply say no.
- rmetzler 6y ago
  I also had similar interactions, but I'm not sure of the outcome, because I don't know how much it aligned with the project's roadmap. And this is exactly where I disagree with Antirez' post. > You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality. Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?" If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself. Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released. So I would urge developers who opensource their code to establish what their users can expect.
HashingtheCode 6y ago
> A new idea is insinuating in social networks and programming communities. It’s the proportionality between the money people give you for coding something, and the level of demand for quality they can claim to have about your work. This is amazing and revolutionary indeed. Imagine a world where people get paid try to produce the best code possible as opposed to hobbyists who slap together code just to get the thing working. Revolutionary indeed. Reminds me of this photo: https://i.imgur.com/R9rnmXv.jpg?2 https://i.imgur.com/R9rnmXv.jpg?2 BTW, this is called humour. So downvote if you have none.
dustingetz 6y ago
Conflict of interests. Also it's in the interests of maintainers to understate the value of their users.
gizeta 6y ago
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. At the same time, I greatly resonate with this need of quality and this brings to my mind this book [https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...]. 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.
hjntmp 6y ago
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?
sombremesa 6y ago
This doesn't seem like a paradox at all - isn't it a well known fact that intrinsic motivation trumps extrinsic motivation?
pedro1976 6y ago
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.
sally1620 6y ago
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.
frank2 6y ago
>don’t do the error of reducing the interaction to a vile matter of money 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).
- srtjstjsj 6y ago
  It's not "the Italian labor market". Antirez's open source work is financed by his corporate employers, so of course he has no need to take payment for bug fixes in his project.
  - frank2 6y ago
    You didn't catch my point, but never mind. (I probably should've written "a certain way of thinking about the morality of work and of money".)
geophile 6y ago
"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian. 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. 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.
nix23 6y ago
>Like a writer will do her best when writing that novel that, maybe, nobody will pay a single cent for No problem, it's just about woman's who write...not the job of writing.
CyberRabbi 6y ago
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. 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.
- srtjstjsj 6y ago
  Anything anyone enjoys doing is no better than drug addiction?
  - CyberRabbi 6y ago
    I never made such a claim, explicitly or implicitly. I think you’re projecting an argument.
tracker1 6y ago
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. 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 finish 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.
mdoms 6y ago
Money isn't vile. What a toxic way to think about work.
coldtea 6y ago
>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. 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... 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...
ngcc_hk 6y ago
The real underlying issue is a) how to deal with public goods especially networked public goods. b) The production cost vs use cost. c) we act on margin always not on total as my mind may think but our act is temporal.
Andrew_nenakhov 6y ago
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.

368 points by stargrave 6y ago

SZJX 6y ago

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

outsomnia 6y ago

> and not when doing copyrighting work for a well known company copywriting > 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. 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.

antirez 6y ago
Signaling bugs is as much work as it is to send a patch. Sometimes is even better work. For instance a bug report that is the fruit of a deep investigation is worth a lot more than a weak patch that is fixing the problem in the wrong way, often because of lack of understanding of the system. I don't agree there is a clear distinction of patches and bug reports in which one is work donated to the project and the other is not. Thanks for the report of the typo, I fixed it and appreciated it even if you didn't send a patch to my post.
- outsomnia 6y ago
  > Signaling bugs is as much work as it is to send a patch. No it isn't. Adding new features a user wants, providing a way to test them and confirm they build and do what they're supposed to in different platforms is a huge amount of work that needs deep specific knowledge of how the app works and what is maintainable. Reporting problems is useful and necessary. But don't compare it to actually contributing to the app.
  - rbarrois 6y ago
    It depend on the actual patch, and bug report. I sometimes receive patches where the contributor just tried to shoehorn the feature they wanted in the codebase; they didn't understand the project architecture, just found a way to get it working. And I may receive a bug report where the user bisected the history to find which commit introduced the bug, and provide me with all inputs to confirm the issue and reproduce it myself. Even if the latter contribution doesn't fix the bug, it will end up being merged: they found an issue, dug to find it; but they don't how to fix it while keeping in line with the library's internals. In other words: the more a contributor tries to understand your goals and design as a project maintainer, and respects them, the more valuable their contribution — be it bug reports, documentation improvements, blog posts, or patches.
    - outsomnia 6y ago
      It seems we agree eg, a paid dev's feature request is not comparable to the paid dev contributing the feature itself via discussion with the maintainer. Nor is it comparable to the maintainer stopping what they are doing to sit there and provide the feature as if their time was worth less than that of the paid dev who wants to consume it.
      - jka 6y ago
        Regardless of whether the contributor is paid, I think that feature requests and bug reports can be compared to feature implementations. If the feature request includes, for example, technical architecture and product design analysis, and illustrates that it has considered various other options, it could be highly valuable. A bug report could have involved significant debugging to identify approximate causes, affected versions, and potentially-related commits that introduced/regressed the bug. All of the above applies to documentation and support commentary too. There is a spectrum with any contribution from 'minimal' to 'thorough', and there's not necessarily a causal link between high-value contributions and paid work.
MaxBarraclough 6y ago
At the risk of mirroring antirez's response, and on top of that I suspect I might be misreading you, but still: > 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. A good bug-report isn't merely whining, it's a contribution to the quality of the project. It takes some amount of time and effort to file a decent bug-report, and it helps the project better achieve its goal. It's less valuable than a good quality pull-request to fix the issue, but it still counts. (The same is true of good quality feature-requests, but to a much lesser extent in my view.) That's different from someone having a sense of entitlement. Unless you're on their payroll, you aren't obliged to prioritise their bug. More generally, you aren't obliged to continue your involvement in the project in any way.
sidlls 6y ago
I've come to view OSS as the software industry's inferior analog to waiting tables in the movie business. It's inferior because at least waiters are paid for their labor. The OSS authors who are successful are also paid, of course: but at that point they've "made it" and no longer have the same concerns (e.g. paying bills) that the 99.999% of other OSS developers have.
- 0SSawayyyy 6y ago
  That's an interesting take; I view OSS as an act of generosity. It's a gift given by the author, without any expectation of reward. Waiting tables in the movie business feels more like a hustle; people do it so they can live in LA or Vancouver while they seek fame and fortune. I have seen a trend of fame/fortune-seeking in OSS recently, but it seems more like a toxic offshoot than the norm. The best OSS projects are still made by people who are genuinely trying to share solutions to common problems. Maybe they "make it" financially, but that is orthogonal to OSS contribution.

the-dude 6y ago

What is the paradox? I don't see it.

antirez 6y ago
That the OSS writer cares and is often willing to fix code she writes for free, more than the other paid work she does.
- the-dude 6y ago
  Ok, I do see that. Somehow the title does not work for me, but that is o.k. I guess. To get back to your point, I like to call it 'play' ( vs work ).
  - antirez 6y ago
    Yep, the title is not a perfect match with the text indeed. I documented our interaction in the post.
mr_toad 6y ago
In economics it’s known as the subscription equilibrium.

ketzu 6y ago

> Open source is different I believe the attributes given to open source here are wrong. 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. 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. > 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. 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. 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). 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.

franciscop 6y ago
> There is a ton of open source code that is crap The good thing of open source is that people pick the best available, or at least some that is "good enough" when there are many choices. The bad thing of proprietary code is that you paid for that, so you are stuck with it. Throwing it again and redoing it has a high cost, staying with it has a (high?) cost. But if you want custom code or very specific code, it's going to be one-off. So yes, in general you can say that open source has better quality, because the best rise to the top, while in proprietary code it is what it is.
- ketzu 6y ago
  I believe that you could easily turn around the argument: To stay relevant with paid software you have to make something people will be willing to buy. If you produce bad software, people will not or at least stop buying it. You can dump everything into the open source domain without any restrictions. Therefore, commercial code is of better quality. It's not that I believe this, I find neither of those convincing. There is great open source software and there is great commercial software. There is a huge amount of bad software on both seids either. Is good open source software better than good proprietary software? Depends on what are the criteria for good, but I don't think that's something we could state as general as "open source is better." Going back to the original article: The distinction the article talks about seems to be personal motivation to make the code better. While there might be a shift to be more engaged in a personal project (which is likely) the licensing model of that personal project is fairly irrelevant for this. Futher, quite a lot of people are also engaged in their job and care about the product they are working on. Are people that don't care about it on their job more or less likely to even start personal projects? To contribute to open source? I don't know, maybe there is some data on that.

junon 6y ago

Some context for readers: This is Antirez, the creator of Redis. Dude's insanely smart (saying this not yet having read the article). EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.

antirez 6y ago
NP and thanks for the nice words.
JorgeGT 6y ago
And the creator of dump1090! When I was a student receiving Mode-S transponder was so expensive, we had a shared receiver/decoder for the whole eng. school. Now that I lecture there I show the students a $6 RTL-SDR with dump1090 to show how far open tech goes, plus some MATLAB code to store/plot the aircraft data: https://github.com/JorgeGT/PlotRTL1090 https://github.com/JorgeGT/PlotRTL1090

MaxBarraclough 6y ago

> 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. Open Source does not always mean hobby project. Plenty of people make a living writing Linux kernel code, for instance. edit: ketzu beat me to it.

pjmlp 6y ago
When employed by big companies to do so, because their main business is selling something else unrelated to the software itself. Doing open source where software is actually the real product usually ends up in hobby project level as donations, consulting or books aren't enough to keep the ball rolling.
srtjstjsj 6y ago
antirez himself made his living writing open source code for redis, until July 2020.

mjw1007 6y ago

When I file a bug report, I often feel I would like to add a disclaimer, along the lines of: « 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. » 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.

tenkabuto 6y ago
That's an interesting distinction. It's like simply documenting that a bug exists versus arguing that a bug exists and should be resolved. The latter feels similar to making a feature request, which can also be done in Issue trackers like GitHub Issues. Maybe the fact that both the former and the latter are allowed/encouraged to exist within the same tracking systems somewhat contributes to the confusion/conflation of the former with the latter.
kzrdude 6y ago
If you would mean it, I think it's nice to instead sign off the bug report with something like this "X is great, and thanks a lot for developing it" - when you're reporting something to a project where you are not previously known.
FartyMcFarter 6y ago
Is this really necessary? If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed? If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.
- pydry 6y ago
  I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected). Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it. I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs. Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.

cinquemb 6y ago

> they care about the same thing you care: your software quality, grandiosity, perfection. Nope, I don't care about this at all. 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. 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.

ricardobeat 6y ago
You haven't realized you're actually agreeing with him. If someone sends a bug report to your router firmware project, what do they really care about?
- cinquemb 6y ago
  I wont care (unless im curious enough to explore it), if they want to write a fix themselves they can do it. And if they write a fix, I wont care about it's quality, perfection or grandiosity… and I won't assume that they do either. I don't agree because I'm not making an assumption for others motivations of writing software (or submitting bug reports), nor do I want to. If you and the author want to assume that these are the only motivations can exist in open source software, then that's on you both, I don't have to assume such things.
  - srtjstjsj 6y ago
    Perfection and grandiosity are a thing apart, but certainly you care about quality... Otherwise you'd play video games with fake chemistry instead of study real chemistry, no?
    - cinquemb 6y ago

Dean-DAGsHub 6y ago

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?

detaro 6y ago
It's both a loud minority thing (that's still quite draining to be exposed to) and very unevenly distributed between projects/maintainers. E.g. projects aiming at non-/not-so-technical users often have problems with it, especially if they at the same time are in areas where regular breakage is to be expected (e.g. software to scrape/download from popular websites, 3D printing tools would be my guess for good examples). Some projects with corporate users but no corporate backing can run into the same. But at the same time for other projects it might never happen.

mcint 6y ago

Once we’re fed, we can contribute to the gift economy, and homestead our own place in the gnoosphere.

jlokier 6y ago
+1 for "gnoosphere". May it be named word of the year one of these years :-)

bboreham 6y ago

Maybe we need to distinguish “altruistic open source” from “corporate open source”?

antirez 6y ago
Yes, we need. I call it "indie OSS" vs "Company OSS".
- jka 6y ago
  There are probably some parallels here with music; some people produce (and may collaborate on) music for pure enjoyment and the craft, and at the same time there are large businesses that have industrialized music creation.
- eternalban 6y ago
  GPL contra the rest of OSS licenses seems to map to this divide fairly well, don't you think? My impression is that Corporate legal seems to not like GPL, at all. So next one, make it GPL.

fierarul 6y ago

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. It's also quite idealistic. 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. Having experienced something like this my conclusion is that open source in any continuous form is to be seriously avoided.

acdha 6y ago
I’ve had similar experiences but haven’t drawn the same conclusion. I haven’t given up on being able to change the norm where a lot of open source users act like they have an enterprise support plan while actually contributing nothing.
- fierarul 6y ago
  Funny thing: I had my email on a commercial support page for, you know, companies that wanted to pay money for custom work. 100% of the emails were from companies asking various questions; everybody took that page as priority free support for companies. I just removed my email in the end.
  - acdha 6y ago
    That’s a really common behavior. I’ve had people open issues stating that something is a production blocker but of course they can’t contribute time to fix it.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
6y ago

detaro 6y ago

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.

ricardobeat 6y ago
Well, that used to be the case for the majority of OSS. Even when funded by enterprise, the main reason to publish code has always been to share and advance a field, not to make more money out of it.

bobmalone123 6y ago

OP could drop virtue signaling by stopping to write in 3rd “female” person (“she writes software”). Statistics talk.

agumonkey 6y ago

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.

nakedrobot2 6y ago

*YMMV 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.

nvlanders 6y ago

Open source authors are annoyed, in descending order, by: 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. 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. It leads to the same dynamics as Mao's cultural revolution, which was not really a success. [1] Not in this case of course.

ricardobeat 6y ago
> mostly by people who do little programming but take over OSS projects You're voiding your whole argument by disqualifying any opposition like that. Anyone disagreeing with you will now fall into that bucket, and give you a reason to ignore them. Can we save that for politics please?
l0b0 6y ago
Some open source authors are also annoyed by: 5) Reporters not spending hours getting familiar with the build system to verify the bug in origin/master, even though it's been there in the three last stable releases. 6) Not providing a patch. 7) Not using the appropriate jargon for everything. Entitlement is very much a thing (on both sides of the fence), but these are going to be extremely off-putting for anyone who is only ever going to be an end user.
- sidlls 6y ago
  Maybe those OSS authors ought to document their software better. A pithy README.md with a toy example nobody would ever actually learn anything from isn't documentation. Maintaining a proper changelog with links to relevant issues/tickets isn't that hard, but it's rarely employed.

projektfu 6y ago

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. 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. There's two little diseases in OSS. 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. 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.

NewEntryHN 6y ago

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

logicOnly 6y ago
This makes me think I should take emails/comments less important. These are not customers, they are fans. If it's my project,I should just enjoy it for myself. While it sounds great to personally respond and research what people tell me, it's a major distraction and time waste when I could be doing research.

lichtenberger 6y ago

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: https://github.com/sirixdb/sirix https://github.com/sirixdb/sirix 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: https://github.com/sirixdb/sirix-svelte-front-end https://github.com/sirixdb/sirix-svelte-front-end 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 https://sirix.io https://sirix.io and stuff like a logo and so on :-)

josteink 6y ago

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. 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? And this lack of concrete reward makes it easy to burn out unless you really care about what you do. This is a real problem. Sure. 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. People should tiptoe around and be afraid to interact, lest they disturb this poor and over-worked maintainer! Needless to say, I think that’s wrong. Open-source thrives on positivity, on energy and a willingness to contribute. We shouldn’t make people who wants to contribute afraid to do so, simply because some maintainers are burnt out. 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 away from open-source. 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. There’s no shame in taking a break. Disclaimer: open-source enthusiast, contributor and maintainer.

xfred 6y ago
It isn't that easy. If your project is very high quality and you let others take over, you'll be forgotten in a couple of years and others take the credit. Often without doing much except responding to rude bug reports like a trained hotel receptionist. But that is frequently the real goal of those who drive out high performers.
jlokier 6y ago
> if you let someone else carry the flame from now on Ha! For a lot of open source maintainers and projects, that's not an option because there isn't someone else. A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that. It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on. Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't. It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all. That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself". That's not maintainers being unwilling to step aside. There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features. Or more reasonably, which just clash with the design direction of the project. The same happens in the real world (non-computer) non-profit volunteer projects. A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.

rushabh 6y ago

I think most people forget that when you (or anyone) puts something out there in the public domain, there is no obligation / entitlement on either sides. 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) Any warranty or service request must come with some form of contract between the user and creator. We as a community must help in people understand this. Open source is not a contract. No one is entitled to anything.

ChrisMarshallNY 6y ago

> 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. This has been my experience. I have refined my development skills, as a direct 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. 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. 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. 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. I really feel that if I had remained "in the mix," I would have stunted it. As Twain once put it: "I cannot help but notice that there is no problem between us that cannot be solved by your departure."

moron4hire 6y ago

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.

agwa 6y ago

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

deleted 6y ago

[deleted]

jancsika 6y ago

> As somebody said, the best code is written when you are supposed to do something else Offer not good for user interfaces. :) At least in the Gnu-slash-linux world it's like this. I once fixed a volume slider widget where the lowest value was almost 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. 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. 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.

srtjstjsj 6y ago
Please don't post flamebait here.
a1369209993 6y ago
> > As somebody said, the best code is written when you are supposed to do something else > Offer not good for user interfaces. :) Actually, it's still the best; it's just that that's a very, very low bar, since the competition is actively user-hostile, and looks like it was designed in Photoshop by a graphic designer who never wrote a line of code in their life (often because it was).

unnouinceput 6y ago

Quote: "As somebody said, the best code is written when you are supposed to do something else." 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. 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.

Ironlikebike 6y ago

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.

srtjstjsj 6y ago
The amateur's work held back by what one can reasonably spend without funding.

LockAndLol 6y ago

The HTTPS cert for this website points to redis.io . Don't know what's up with that...

saagarjha 6y ago
The author wrote Redis.

aidenn0 6y ago

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. I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"

boulos 6y ago
Because you kind of did Product Management for them! “Hey, there’s this idea. I have at least one customer [me]. I think it’d be pretty easy to implement like this.” It’s pretty rewarding to have a blueprint for “oh, I can deliver some value, easily”. Got any more suggestions for them? :).
john_moscow 6y ago
That's because your wish happened to align well with the maintainer's understanding on how they want to spend their time. Think of it as hitchhiking, if you're both going the same way, it's a win-win: a free ride for you and a free chat for them. But if they need to take a 100-mile detour to get where you're headed, it makes full sense for them to simply say no.
rmetzler 6y ago
I also had similar interactions, but I'm not sure of the outcome, because I don't know how much it aligned with the project's roadmap. And this is exactly where I disagree with Antirez' post. > You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality. Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?" If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself. Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released. So I would urge developers who opensource their code to establish what their users can expect.

HashingtheCode 6y ago

> A new idea is insinuating in social networks and programming communities. It’s the proportionality between the money people give you for coding something, and the level of demand for quality they can claim to have about your work. This is amazing and revolutionary indeed. Imagine a world where people get paid try to produce the best code possible as opposed to hobbyists who slap together code just to get the thing working. Revolutionary indeed. Reminds me of this photo: https://i.imgur.com/R9rnmXv.jpg?2 https://i.imgur.com/R9rnmXv.jpg?2 BTW, this is called humour. So downvote if you have none.

dustingetz 6y ago

Conflict of interests. Also it's in the interests of maintainers to understate the value of their users.

gizeta 6y ago

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. At the same time, I greatly resonate with this need of quality and this brings to my mind this book [https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...]. 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.

hjntmp 6y ago

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?

sombremesa 6y ago

This doesn't seem like a paradox at all - isn't it a well known fact that intrinsic motivation trumps extrinsic motivation?

pedro1976 6y ago

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.

sally1620 6y ago

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.

frank2 6y ago

>don’t do the error of reducing the interaction to a vile matter of money 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).

srtjstjsj 6y ago
It's not "the Italian labor market". Antirez's open source work is financed by his corporate employers, so of course he has no need to take payment for bug fixes in his project.
- frank2 6y ago
  You didn't catch my point, but never mind. (I probably should've written "a certain way of thinking about the morality of work and of money".)

geophile 6y ago

"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian. 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. 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.

nix23 6y ago

>Like a writer will do her best when writing that novel that, maybe, nobody will pay a single cent for No problem, it's just about woman's who write...not the job of writing.

CyberRabbi 6y ago

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

srtjstjsj 6y ago
Anything anyone enjoys doing is no better than drug addiction?
- CyberRabbi 6y ago
  I never made such a claim, explicitly or implicitly. I think you’re projecting an argument.

tracker1 6y ago

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

mdoms 6y ago

Money isn't vile. What a toxic way to think about work.

coldtea 6y ago

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

ngcc_hk 6y ago

The real underlying issue is a) how to deal with public goods especially networked public goods. b) The production cost vs use cost. c) we act on margin always not on total as my mind may think but our act is temporal.

Andrew_nenakhov 6y ago

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.