The open source paradox

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

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.

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.

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.

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.

  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 leads to the same dynamics as Mao's cultural revolution, which was not really a success.

[1] Not in this case of course.

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.

I was all "WTF are you thanking me for? You just made my life better for free at my slightest whim"

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.

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.

EDIT: I see he's here in the comments. Apologies for speaking for you, Antirez.

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

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

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

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.

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_...]. In an environment obsessed with growth (more customers, more downloads, etc.) it is often difficult to make long-term choices which gives to quality the right level of importance.

I don't 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.

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.

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

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 and stuff like a logo and so on :-)

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.

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

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.

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.

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.

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.

No problem, it's just about woman's who write...not the job of writing.

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.

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.