Hacker News Reader

Comment by danShumway | Hacker News Reader

It seems like this shouldn't be the case, at all. Commercial software has a more obvious reason to avoid breaking your stuff and to try and track down bugs.

But surprisingly, I've noticed the same thing -- that for me, Free software tends to break less often than proprietary software, that it tends to introduce fewer breaking changes to my workflows, and that when it does break, it tends to get patched more quickly and to (at worst) be easier to work around.

This is highly anecdotal (and there are some exceptions). I wouldn't make a general, bold claim like the article is making about it. But noticing that general pattern with the software that I use has been one of the biggest driving forces behind me adopting more and more Free software into my core workflows as a policy. In general, if a Free alternative to a proprietary solution exists, I'll choose the Free one even if it has fewer features, because I assume that the proprietary version will eventually be more trouble than it's worth, or that it will eventually break in a way that significantly disrupts what I'm trying to do.

I'd be skeptical of saying something empirical about that, I don't know that other people using other software wouldn't have different experiences than me. But I do find myself kind of nodding along with the article. A lot of the Free software I use, I use for practical reasons -- because I want to get work done, and I don't want my computer to break while I'm trying to get work done.

Other people's mileage might vary.

View on HN

Commercial software usually has a support team working frantically behind the scenes trying to keep the wheels on, while the engineers are under presser to add more bells and whistles rather than improve the core application. Support issue caused by bugs are just a cost of doing business. Obviously you need a certain amount of reliability to keep those costs from putting you out of business, but less than you might think.

Free software sinks or swims based on how it works when nobody is there to support it. So the reliable stuff rises to the top.

There's also a self-selection bias here. FOSS software tends to attract people who are interested in FOSS, and they tend to be knowledgeable, or is a tinkerer/DIY'er.

Commercial software is often used by unwilling users. These users aren't interested in the software, and are often not well versed in IT or have an uncontrollable environment they cannot tinker with. Therefore, any failure caused by their circumstances are attributed to the failure of the commercial software.

Therefore, FOSS software may seem more reliable because the people using it has more competency in using it, has more control over their environment and may even be willing to elbow-grease a DIY fix/hack.

This is pretty close to the mark. As far as I can tell, after the Bell System got broken up in 1982, the government turned a lot of their IP into IEEE/FIPS/ISO/ANSI standards (e.g. X3J11, POSIX.1) and then made compliance mandatory. So businesses sprung up to provide compliant solutions, not for love of the technology but to cash in on the gravy train. Great example is the Windows POSIX subsystem where you can really tell that the intent of the folks who built it was basically just to check off a box.

Hmm.

You could say there is a self selection bias with millionaires having pricey stuff too... but that sounds like another reason it is reliable - i.e. its typically made for users who know their stuff versus made by the users who barely have an inkling...like getting your car designed by a mechanic versus getting it designed by a 5 year old who thinks big engines and tail pipes look cool...

Often those in management tend to have a relatively infantile understanding of software and design, let alone the understanding of their problem domain...

My impression of FOSS is that it's very heavy on total rewrites, as that is what attracts engineers. So, you end up with a lot of underbaked variants of the same thing.

Hmm, interesting theory...I think its more that forks are a thing - with a traditional product if snr mgmt dictates xyz must happen, rare is it even the consumer gets much say - with FOSS if it doesn't work right or does something dumb you can normally fork and go a completely different direction.

So I guess yeah if there are 100 ways to skin a cat you will get 100 different approaches, but then that's where the market comes along and mostly only the best 'rise to the top'.

Also, don't pretend complete re-writes with dubious value don't happen in big biz...its more common for something to be pronounced 'unworkable' and a complete rewrite mandate be issued, usually because a product had ossified to the point nobody knows what it actually does anymore, normally because companies are bad about investing maintenance time into code.

I think for something such as a unix-style CLI tool that does one thing, and one thing only, non-commercial community-driven development works great.

For anything else, not so much. It is not possible to imagine a video game produced by an open community, because it requires the vision of an auteur, not design-by-consensus. That requires hierarchy, or solo development. Both realistically require a lot of resources and thus are overwhelmingly commercial in nature.

The year of the linux desktop seems to never arrive because all of the support and integration of the various components requires constant application of labor by an army of people, if it is to be usable. Android and Ubuntu might be able to succeed, but "the community" will not.

The community can maintain stuff that is "boring," where there is no controversy. When the right approach is clear to all. The community can write an emulator, but cannot write a video game. It can write a kernel, but cannot support a whole distro that "just works" for normal people.

Maybe in some distant future when there is no constant churn of new features and drivers and rewrites then we can have an open community-maintained distro that actually works for a normal person. Doubt such a time will ever arrive, but if it did then and only then would OSes become boring.

Web rendering engines are complex and happen to be open source nowadays, but are commercially supported and wrapped in proprietary packages. Mozilla is failing to keep up with gecko, so the last non-commercial rendering engine is dying a slow death. It was able to succeed somewhat because following standards is straightforward and thus can be considered "boring." Some have likened browser development to emulator development.

But packaging it all up nicely and providing the best possible user experience? I wouldn't count on it.

> because it requires the vision of an auteur, not design-by-consensus

I've worked on enough commercial software to know that most large, practical products aren't designed from an auteur perspective, and that many that are, shouldn't be. My perspective on game development is different than it is for tools -- some of the most impressive OS tools I've seen (Blender, Krita) are where they are specifically because they've been designed by committee, and because it turns out that a committee of artists generally produces better art-tools than a committee of programmers and marketers.

> The community can maintain stuff that is "boring," where there is no controversy. When the right approach is clear to all. The community can write an emulator, but cannot write a video game.

A good 90% of the tools where reliability matters are boring, and I want them to be boring. I compare this to other tools that I use outside of a computer. I don't want a radical piano when I'm composing music, I want a finely tuned, boring solution. I don't want radical pencils, I do most of my artwork with tools that I know extremely well.

When I picked up digital drawing, my approach was the same; I didn't want an auteur experience, I wanted extremely consistent drivers, and consistent software that allowed me to focus on my artwork, not the user interface.

I think you're hitting on an interesting artistic point with game development, but you're misapplying that point to a field with different concerns. I use Linux because it's boring. It gets out of my way and lets me focus on creative tasks.

That isn't true of Blender at all, it was built by one software company from 1994-2002, quirks and all.

Open software runs the gamut from anarchic, to focused community development, to benevolent dictatorship, all the way to closed-development models, and I can cite success stories from all of those approaches. Just pointing out that Blender isn't a good example of design by committee, it's still essentially the same program it was when the Blender Foundation was established.

> it's still essentially the same program it was when the Blender Foundation was established.

I completely disagree. Blender's interface has undergone a large number of revisions since the original program was launched, even prior to its giant 2.5 rewrite.

I chose Blender as an example in part because I think its single-company origins make it a better example of how Open committees can improve UX. Blender in the early-to-mid 2000s had a strong reputation for being unintuitive and hard to use. It's only because of some really hard work from a dedicated community that Blender doesn't have that same reputation today -- and I don't think it's a terribly controversial claim to say that Blender's close relationship with artists has been one of the elements that has elevated it so far above other art tools on Linux (see Gimp), and that has allowed it to make so many smart iterations on its UX over the years.

> and I can cite success stories from all of those approaches

Sure, I do agree with that. I didn't mean to suggest that the community development model is the only way to write software; just that the community development model is a viable way to write software (especially for creative tools) and that it shouldn't be dismissed.

There are several 'auteur' style programs that I love that I think would have benefited from having more community involvement in their UX design. Git has a wonderfully elegant core; it definitely benefited from having a single person come up with the idea. But the CLI that was built around that core is really bad, and would have benefited tremendously from having more input.

There are also a lot of single-dev OS efforts that shine. But I don't think that's the only way to design software, or that community-run design should be dismissed because they exist.

That's fair, although Krita still seems like a more central example, since without the original, complete program, there's no Blender at all.

As I get older, I have more moments where I'm saying to myself, but I've used Blender! It's kinda unintuitive and hard to use! and then realize that, er, that was in 2010, and it's now a solid decade past that...

I happen to think the common narrative of git having good plumbing and bad porcelain is still considerably overselling the virtues of that program, but, that's a topic for some other thread.

Eh, gits porcelain is wildy successful for how 'bad' it is. There are a million attempts to 'fix' its porcelain, mostly related to somebody's wish to meet some arcane workflow...

But for standard development (and with some sort of gitflow) most people need only ten or so commands to operate an otherwise complex algorithm for diffing and merging code, compared to the inexorably complicated UIs which at best offer the basic ten and then usually ten more random local idioms, or at worst don't offer the basics and still have the extra complexity...and then offer to drop you to shell for anything else...

> It is not possible to imagine a video game produced by an open community, because it requires the vision of an auteur, not design-by-consensus.

A lot of modern videogames use art assets and define gameplay behavior with JSON. Stallman says proprietary data and art is allowed in free software.

To the extent that corporations are capable of producing "Free Software" as defined by Stallman then I would find it likely that they would succeed, but the comment I replied to argued that commercial software was inferior and that seems obviously false outside of what I called "boring" stuff. But I think the boring stuff is really important and good, and wish more things became "boring" in the sense of being solved problems rather than open problems.

Battle for Wesnoth might be a counterexample to your argument about games: http://wesnoth.org It's an open source video game that's of high quality with good user experience, developed by lots of folks over a long period of time and available on many platforms.

See also some rougelikes, such as Cataclysm: Dark Days Ahead or (IIRC?) Dungeon Crawl: Stone Soup, which are often strong examples of open-source development, though perhaps as many are one-man teams.

I think it depends on the type of game. It’s hard for me to imagine something like Celeste, Cave Story, or Journey coming about through the open source process. These games had very specific artistic visions, and I’m not sure how you’d execute that.

(A small team could perhaps release a game under an OSS license, but it wouldn’t be what we generally think of as open source development.)

...here’s the thing though: I don’t really games to be software. I mean, of course they are software in a literal sense, but then an Encyclopedia and Harry Potter are both books.

> A small team could perhaps release a game under an OSS license, but it wouldn’t be what we generally think of as open source development.

This is... definitely what I think of when I generally think of open source development? The vast majority of open source projects seem to be by one person. How many zero-star projects are there on GitHub? Half the libraries I use on a regular basis are authored by one person.

I think you are conflating contribution with direction. I'd argue most successful OSS projects have strong direction led by a small team. Postgres core. Python's BDFL, while it lasted. Even projects like Git have people like Junio, who are wonderful and knowledgeable and without which the project wouldn't even be remotely the same.

> These games had very specific artistic visions, and I’m not sure how you’d execute that.

There is no requirement for consensus-driven democratic decision making for a project, so I really don't get why you feel this way.

One of the first projects I contributed to was BZFlag, a game.

What about Colossal Cave Adventure? Rogue? Nethack? Hell I spent probably a few dozen hours playing Tux Racer since it's release.

I would argue that the situation is quite different.

Open source is quite good in two domains: large collaborative efforts where the collaborators may have diverging or competing interests, as well as addressing the needs of the open source community.

This has nothing to do with CLI verses GUI. There are many excellent GUI based applications. The lack of game development has little to do with the vision of an auteur. Game development simply depends upon a rapid development cycle and hasn't fared well with the more iterative approach of open source software. Open source software is often more radical than boring given the freedom to experiment with ideas. There are also plenty of people packaging it up nicely to provide the best possible user experience. Quite frankly, the user experience from a competently managed Linux distribution is better in most respects than its biggest competitor.

The lack of adoption of open source likely has two sources: first is that it doesn't have the marketing muscle of the commercial alternatives. Heck, most people are blissfully unaware that they are using open source software or software with major open source components. The second is that the open source world is more accessible to people with a deep interest in technology. It doesn't matter how friendly the software is when you actually have to discover what is available then decide upon what reflects your needs.

So, as someone who has worked on both commercial and open-source video games, I can say this: You're wrong in a way that is non-obvious without getting really deeply inside the creative perspective.

The thing that games accomplish is to allow a study of some idea. The idea can be frivolous like Mario's jump and run, it can be a grim war simulator, it can be a portrayal of biographical experience or a mathematical exploration.

But the intent of the vision, whatever it is, is negotiated between the author and audience as with every experience. This is why players of online games fret so much over small balance patches: is the game going closer to, or further away from, their vision? When it's open-source, author and audience are nearly the same, and so the loosely encompassing visions with broad-sweep productions that tend to be produced by commercial teams are mostly filtered out: in their place is a sense of evolving play to the extent that the game can encourage further study and development.

Open game projects that are positioned to allow study through the development itself do well: People like contributing to Nethack because it's intrinsically interesting to work on, and the basic gameplay is such an established formula that it's not hard to accumulate more on top - development just extends to new scenarios indefinitely. On the other hand, visual novels are best suited to open engine tooling, because the study goal is not accumulative - you don't add more characters and subplots to develop a story - it's to use a common framework of storytelling and fill it up with a specific kind of study of your choosing, a mode of portrayal and thematic content. It would be like if Nethack supported alternate gameplay models that happen to share the style of graphics and menus. Even though visual novels tend to have simple rulesets, they all differ from each other.

And I do agree that where proprietary stuff succeeds most is in that "singular new vision" context: but the moment you start generalizing and adding configuration knobs, it loses steam, and in the perspective of study, gaming often needs some configuration so that the space is further explorable.

I will say that some of the best gaming communities have an active modding scene, and ideally that scene is intentionally fostered by the gaming company. Elder Scrolls is the obvious example. It was made far better by the community, and that symbiosis created something better than either could've individually.

But the companies can produce something quite impressive without a community, whereas the reverse isn't true.

And the modding scene follows the same kind of trend where Total Conversions require an auteur, but the community as a whole can cooperate on unofficial patches, graphics overhauls, and the like.

> It is not possible to imagine a video game produced by an open community, because it requires the vision of an auteur, not design-by-consensus.

I'm impressed with 0 A.D.[1]

Desktop Linux is also at the point where if a Chromebook would satisfy a user's use case, then so would something like Ubuntu. I've had my parents on Linux for a while now, and it just works.

[1] https://play0ad.com/

0 A.D. was a commercial project that was open-sourced, not a community project.

I think a big problem with open source games is in the vfx side of things where the work that needs to be done is long and arduous, it needs to have a coherent visual language and gfx artists just don't seem very interested in doing that. Plus for a lot of gaming platforms that are relevant you have licensing fees etc which are big blocker for FOSS projects.

This is a really broad brush.

Oracle DB will fail less often than a python open source utility with 10 stars on Github.

It really depends on the scale of the project and how many people are contributing to it, and its momentum going forward - commercial or open-source.

I've had MATLAB engineers fix a compiler bug in 2 hours while I was on the phone line with them. Sure, it costs my company $13k/year for the license but when you have a jet engine hoisted up for testing and its costing the company thousands of dollars of loss time, yep, commercial software or open-source software with solid support is a must.

Proprietary software sometimes is quite good if not the best in class. There is no need to pick up pitch forks and large brushes to pain everything red. If nothing else, it shows how misguided, immature and closed-minded some of the GNU folks are. Most of the open source contributors are nice though, and I don't wish to ironically generalize everyone.

GNU Octave appears to have some commercial support vendors listed, that probably wouldn't mind receiving $13k/year in exchange for answering the phone: https://www.gnu.org/software/octave/commercial-support.html

That sounds great! Why can't both proprietary software and open source software co-exist? For startups and small companies, open source software is great. For large enterprises, the cost of the software is a vanishingly small % of the cost, and in fact they don't care as much - a lot of large enterprises are continuing to open source their own internal tools.

MATLAB has over 2 dozen toolboxes, with insanely detailed documentation. We are actually very happy to have MATLAB and our engineers are trained to use it for decades. We gladly pay for it. It would be a massive undertaking to go GNU Octave even if it did everything MATLAB did. I think we are getting stuck in the weeds, the point is:

We are engineers. Software is a tool to get the job done.

There are many other packages that cannot compete with anything open source - ANSYS Mechanical for example.

Would it really be “a massive undertaking to go GNU Octave” when its syntax is a superset of MATLAB’s?

Either way, in the longer term I think saving a bit of money wouldn’t hurt, spending some sponsoring Free software could eventually catch it up to competitors, and having Free industry standard tools more easily accessible to future engineers to begin decades of training earlier could benefit enterprises.

I don’t mind paying for software I guess.

> Would it really be “a massive undertaking to go GNU Octave” when its syntax is a superset of MATLAB’s?

Does anyone actually use MATLAB just for the "MATLAB" part of it? Where I work, it's the Simulink part that's locked us in... I'm still not sure how MATRIXx withered away and gave Mathworks free reign in the control systems design space...

>Why can't both proprietary software and open source software co-exist?

Probably because it's impossible to have code that is both proprietary and open source at the same time. Unfortunately the code is either public or it isn't, because of copyright law there's not really an in-between.

Don't get me wrong, I'm not saying your company should use any particular product, but you do have options of where you can put that money that you can exercise when it's most appropriate. None of those consultants seem to be as big as Mathworks though, which probably matters.

>There are many other packages that cannot compete with anything open source - ANSYS Mechanical for example.

It only takes one entrepreneur to get the ball rolling by releasing a serious open source competitor. The whole industry can build on top of it after that.

and the FOSSjobs wiki lists similar vendors for coreboot, Debian, LVFS and Samba:

https://github.com/fossjobs/fossjobs/wiki/resources#freelanc...

Speaking of MathWorks, I had the misfortune of having to use one of their less famous offerings (Polyspace) and it was borderline unusable with basic functionality failing out of the box. I believe our license was $50k/year and most of the bugs simply were simply left unfixed after we reported them.

This seems to be par for the course for commercial static analysis tools. The Clang family of tools, on the other hand, has served us quite well but unfortunately they don't perform some of the checks that we need to do for regulatory reasons.

Would you mind telling some of the kinds of checks the Clang tools do not perform? I wonder if they are mostly syntactic or if they need dataflow analyses. (That said, Polyspace has 2 tools now, Bug Finder and Code Prover, whose applications are somewhat different.)

Clang does not check MISRA rules or calculate other metrics that are considered important in embedded industries.

The vast majority of MISRA rules are either purely syntactic (governing things as trivial as variable names) or obvious to the point of uselessness (like "don't violate the One Definition Rule"). The few actually useful ones require dataflow analysis but frankly Polyspace doesn't appear to do a very good job at it. My impression was that it achieved a 0% false negative rate by way of a 99.99% false positive rate. However, we never reported any of these false positives as bugs as the reports likely would have been rejected outright. The bugs we reported were all far more clear, such as the tool refusing to compile perfectly valid code, or glitches in the user interface.

I'm honestly not privy to most of the politics and no longer work in this area, but my impression was that even if Clang were to implement these checks, it would not be taken seriously by auditors as it doesn't come with a price tag or tick other boxes like generating nice PDF reports with violation counts and so on.

Probably depends on the field. Yeah, engineering software might be lacking, but for machine learning tools, open-source runs laps around other proprietary tools (including MATLAB, which would be considered a joke).

> This is a really broad brush.

Unless the person you're replying to edited their original comment, they did the opposite of a broad brush.

The comment clearly specified that what was said was based on personal experience and reiterated that milage may vary.

---

It's difficult to gauge overall quality and satisfaction for any product, even more so when talking: software + open source V.S. proprietary + people with different backgrounds and expectations + possibly different versions.

In my opinion, this is especially true when a good part of people's experiences come from software being used in their jobs. Meaning, they don't have much control over it so they're subject to whatever has been given to them and that highly affects their judgment.

I would use Oracle as a counterexample - while it's very stable, and there is a feature for everything (only some of them are in various extra $$ addon products), however, I was really surprised at the horrible quality and dev-unfriendliness of all the tooling and ecosystem compared to the equivalent open source tools; and the brittleness of their integration with any non-Oracle products, which is a necessity in many larger companies.

While there is a lot of quite good proprietary software, and Oracle is good in many aspects, I would not really call Oracle best in class; in so many situations PostgreSQL would be preferable even if you ignore Oracle licencing (and you can't really ignore Oracle licencing).

If you were willing to pay 13k/year as a support fee, I suspect there isn’t a single piece of FOSS you couldn’t get immediate support turnaround for.

Case in point, Red Hat built a $32B business off of mostly selling support contracts for FOSS. Notionally some amount of that was licensing deals, but the core reason to buy RHEL instead of using Debian or something was because RHEL comes with support.

You aren't wrong, but I do think it's worth pointing out that Red Hat writes a metric ton of FOSS code also which it contributes upstream (or the upstream is entirely RH owned/controlled).

For example, Red Hat is the number two contributor to Kubernetes (behind Google). Red Hat extends K8s with OpenShift which makes K8s a PaaS, and that is also open source and freely available as OKD[1]. RH doesn't get paid directly for that work but funds it with support contracts (which in turn enable landing more support contracts).

I know that doesn't contradict what you said, I just don't want to leave a reader with the impression that RH just tacks on a support contract and makes some money. RH does a huge amount of dev on it too.

[1]: https://www.okd.io/

So then what difference does it make? I am not going to fix the code myself anyways and visibility of the source code is irrelavant.

It is like buying a hammer to nail some nails, I don't care the metallurgy of the hammer as far as it gets the job done. If it fails, I buy a better one.

It's about the relative freedom of the market.

A hammer has well known metallurgical properties, so anyone can make one. You don't care whom you buy from, but you buy a cheaper, hopefully better made hammer because nobody tries to fleece you for a 100$ hammer.

In the world with only commercial knowledge of hammers, they cost 10G, people spend many years and invest much capital into going to hammer school, and maybe even you just rent a hammer at a 13G a year rate with support. Nevermind the cost for say, a screwdriver.

Commercial software has a more obvious reason to avoid breaking your stuff and to try and track down bugs.i

Commercial software has an incentive to pump out new features to get more customers. Also, if someone is only working on something for a paycheck they may not be as thorough as someone working to solve their own problems, or satisfying their passions.

Commercial software has an advantage when it comes to documentation, and being user friendly because they're the things no one wants to do.

This is not true though. It really depends on the company and their philosophy, whether they are publicly traded or what their executive team is like.

Good companies know how to invest into their products and make them world class. In my previous job, we used a wind turbine simulation package developed by 25 engineers and it was so great - they really cared and fixed things. It was $50k/seat/annual license but we were almost like 2 different teams under the same company.

"You scratch my back, I scratch yours".

There are also a lot of companies that have lock-ins and generally awful attitude towards their own products. This also exists in the open source world - there is a lot of awful open source code out there.

> Commercial software has an incentive to pump out new features to get more customers.

Not if it's SaaS.

Vendors of rented software have no economic incentive to develop new features, or even fix bugs, because they get subscription fees without needing to do any work.

There is still competition to consider though. If a SaaS product has competitors that are more reliable, or more feature rich, they should win & retain more customers over time.

Data lock-in, due to proprietary file formats, makes switching software extremely difficult, especially for companies that interchange data with outside entities.

For instance, companies that do design and/or A/V work have no real alternatives to paying Adobe monthly--regardless of how little work Adobe puts into Creative Suite--because it's an industry standard and there are no alternatives that offer friction-free interoperability.

They still have to attract new customers, and investors really want to see growth not just a stable number of subscribers.

My experience is that commercial software has teams of programmers rewarded for velocity. Velocity doesn't encourage good architectural decisions. It rewards building stuff quickly. Most commercial systems I see become rats nests very quickly.

With free software, if I waste a year tweaking something to figure out how to Do Things Right, that's okay. If I'm a downright a-hole about accepting commits (Hi Linus!), that's okay too.

It's different incentive structures.

From my perspective, Linux circa 1995 was just fine. If anything, Linux 2020 is a modest step backwards. I'd rather have long timelines and high reliability. That's not something commercial teams can sustain. People need to keep externally signalling productivity.

Ubuntu and Red Hat are a bit of a wildcard, since they take a hybrid model which seems to be dragging Linux down the path to look a lot like Windows 95, with layers of hairballs upon layers of hairballs. I'm not thrilled about that.

> that it tends to introduce fewer breaking changes to my workflows

Often because they don't have otherwise jobless UX people.

I find open source (gui) software surprisingly more usable than many stuff on windows, because they have predictable old school gtk / qtwidgets layouts. Less eye candy, sure. But I don't care.

My experiences with Ubuntu vs Windows, I did not come away thinking that free software has less bugs in it. This is not to say that Windows has no bugs in it, but I’ve never had my sound just stop working or my WiFi break after an upgrade on a Windows machine.

Perhaps not, but I've had performance issues far, far more often on Windows than on Linux (or MacOS). I mean, you typically can't even go a week without rebooting Windows, or you suffer severe degradation of performance.

Also, I personally have never had my sound just stop working or my Wifi break on Ubuntu since probably 2013 or 2014.

Windows 10 has a pretty awful update history. Among it's greatest hits, it has caused user data loss and rendered some PCs unbootable (including one of my laptops).

IIRC MS has even had to block their own updates from their own Surface devices to prevent bricking. Contrast that GNU/Linux which a majority of desktop users probably run on hardware that wasn’t designed for it — I know I do because I’ve seen plenty of BSODs after updates which took orders of magnitude longer than installing GNU on the same hardware which ran the latter flawlessly.

No, windows updates always had that reputation. Vista, 7, 10. All of them "bootlooped" i.e. an error occurs during update but windows does not delete the failed update from cache.

Imagine being a 13 year old kid with a Vista laptop trying to install .NET Framework because he wanted to play Terraria but then his laptop becomes useless. Of course that is going to breed resentment and fueled my switch to Arch Linux.

I managed to "unbrick" a Windows 10 system by disabling the windows update service and by deleting the cache folder. Windows updates are just universally bad.

> This is not to say that Windows has no bugs in it, but I’ve never had my sound just stop working or my WiFi break after an upgrade on a Windows machine.

Sound just stops working every few days on my Windows laptop. I have also had upgrades break things on Windows. With Ubuntu, while I have had some surprises they are never random and I can fix them. With Windows it's just like... stuff just randomly stops working several times a day with no rhyme or reason to why. It's an organic, nondeterministic, unpredictable system.

That's not to say Windows doesn't fail in repeatable ways, it does that too. I've totally had OS, browser, Slack upgrades break things in really basic ways. But that's something that comes from updating software, the instability... that's a Windows problem that I don't have on Ubuntu.

I don't think a 25 year old paper on the topic would still hold that much relevance today. I'd also suggest that the difference is why software is created could be having an influence over something like this. The fundamentals of the Unix design philosophy are "Make each program do one thing well" and "Expect the output of every program to become the input to another, as yet unknown, program". You could debate exactly how influential that has actually been over GNU design, but it's quite different from the typical approach taken with commercial software, which is not to write programs that perform a single function, but to write programs that solve an entire category of problems for the customer. When I think about the opensource "solution-oriented" products that I've used (Elastic stack and Zabbix come to mind), I don't get the impression that they're more reliable than their commercial counterparts.

One of the things I've always thought about open source tooling in general, is that I expect to find a collection of highly reliable and performant utilities, and I expect it to be entirely my problem to turn them into a working system that's going to solve my problems. With commercial software, I would just expect it to just work off the shelf and consume much less of my time to maintain. That said, it is a fantastic feeling to find a bug or missing piece of functionality and to just write a pull request for it, rather than waiting for an account manager to get back to you saying "it's on the roadmap" or something else equally unhelpful.

I think work arounds being easier doesn't really need any empirical data to back it up. By having the source code, a lot more people will be able to make sense of it and figure out how to change (or even fork) the original software. I'd say that's pretty much a corollary.

On the other hand, I think free software probably tend to break backward compatibility less mainly because it moves at a slower pace (be it because it's designed by committee or just lack resources). With software as a service in special, breaking changes is sort of the industry norm. So, there's also that cultural component to it. But it's difficult to measure the rate at which free software introduces breaking changes vs proprietary software.

Paid software is more user friendly. For non B2B sales usually useability is much more important than reliability.

Also note that open source developers like all humans cannot live without getting paid. This means that most open source developers are usually also closed source developers. Some of you though are lucky enough to get paid to develop open source but that's rare to get paid to develop something that's given away for free.

Reliability aside, documentation for non-commercial free software often hmmm... sucks, compared to commercial software.

Some of the larger free software Communities seem to have decent documentation though, so that's not a 100% rule.

Not sure if that's because they might attract commercial entities who fill in the missing pieces (eg docs), or if other things are at play.

It depends on which Free Software. The paper doesn't really makes an apples-to-apples comparison sadly. GNU has always been the open source flagship. Comparing GNU to SGI is like comparing Google to Yahoo. It'd be more apt to compare the reliability of GNU tooling to the AT&T PSTN.

My organisation pays many $k in "software support". Having been in the open source world where we get along perfectly fine with no support whatsoever, that was a surprise. I am perfectly capable of supporting software myself.

It turns out things are structured in commercial land so you really can't do that. All the usual remedies available to me, like source code, self describing config files, open data formats aren't there. What help the vendor is willing to offer is locked up behind paywalls you can only get past without paying yearly support.

Having run a commercial software company myself, this isn't a surprise. You have to have a continuous, reliable revenue stream to pay those continuous, ever reliable wage bills. If you are making a few large sales a year those sales don't cut it, so you engineer things so you get a regular income from software. One way to do that is to ensure customers regularly run into things that can't do themselves.

A very good example of was in the time before office365 subscriptions. Microsoft arranged to get a stead income by deliberately breaking the on disk format of Office files every year, so the old copies of office could not read files produced by the new version. They would then seed the market by handing out free or very cheap copies of the new version of Office to students, so companies would start getting documents the could not open until they upgraded.

Not providing features only used once in a year, or making them unreliable or difficult to use are other ways of doing the same thing. It's all very ugly, but by its nature software lives forever once you get it right, so I don't know how commercial programming teams would have survived without either subscriptions or pulling some stunt like that.

Free software ≠ non-commercial software

That’s a false dichotomy.

I think this is partly just survivor bias or some such thing. Good open source software is popular because its good, while commercial software might be popular for other reasons like advertising or lock in.

Reply on news.ycombinator.com