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.
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.
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...
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.
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.
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.
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.
> 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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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 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.
In the sense that you don't risk losing everything if the company providing the software (often as service) goes under, stops development or simply decides to "pivot" their product into something else.
If the service is at all useful, some other provider will enter to fill the void. You should never trust any service which doesn’t allow you to download your data, OSS-backed or not.
Free Software is amazing. I love emacs, Firefox, bash, zsh, nginx, postgres, llvm, linux, freebsd, and many other packages. But, I think that there are two points to be made with regard to commercial software.
1: Domain specific programs, and polish. Logic Pro X, Final Cut Pro X, Ableton, Cubase, Premier Pro, are are excellent pieces of software that people pay for and use every day. Where is the free software equivalent that isn't glitchy and has a usable, slick, ui? The more specific the case gets, and the less related to systems a Free Software project is, the less likely it is to exist or have any polish. I can list Postgres, Redis, Linux, OpenBSD, NetBSD, NodeJS, WebKit, SpiderMonkey, LLVM, GCC, Binutils, Busybox, etc., but where is the free software iMessage, Google Docs, Discord, iTunes, Steam, Google Maps, etc. There may be some of these projects out there for what I just listed, but none of them have a userbase as big as that proprietary software. The only things I can think of are VLC, Blender, and Android.
2: Free Software can only exist with Commercial Software. How many people that work in Free Software are software engineers working at a corporation? What pays for this Free Software to exist? Microsoft hosts github, big enough Free Software projects have budgets and employees at other companies paying for all of it.
With all due respect to the author here, the arguments presented aren't particularly compelling.
> Apologists for proprietary software like to say, “free software is a nice dream, but we all know that only the proprietary system can produce reliable products. A bunch of hackers just can't do this.”
Absolutely no one says this anymore. In 2014, when the article was written, almost no one would say it.
> Barton P. Miller and his colleagues tested the reliability of Unix utility programs in 1990 and 1995. Each time, GNU's utilities came out considerably ahead.
That's great, but it's 2020 now.
The FSF has done awesome work, but they might be better served presenting modern research and evidence about the reliability of free software.
That was exactly how I felt too. The examples given were laughable. I get that those are simple programs and it's easier to test them, but if you can't test the bigger/harder stuff easily, how can you make a claim as to which is better?
Free utilities with well-defined success criteria (cat, tac, head, tail, ls, rm, cd, etc.) are generally rock solid. And there are some examples of excellent desktop software (Firefox, KeePass.?.?, GNOME Terminal). However, many GUI applications have the kind of decade-old bugs and UX which means I really can't recommend any of them, and I only use them because I don't trust the intentions of their closed source equivalents.
- Calc seems to have fewer graphing options and mathematical functions than the last Excel I used back in 2009.
- Thunderbird keeps randomly losing emails when dragging and dropping things between folders, and incoming email filters only work some of the time.
- GNOME Evolution doesn't seem to be able to save draft emails while offline, so I just have to hope that I get online to send it before GNOME desktop has one of its moments. Weekly recurring calendar entries seem to be split up into daily recurring ones in recent versions. Search is interminably slow compared to any other client, including Thunderbird.
- Darktable has absolutely oodles of features, but I can't tell what anything does except by trial and error. F1 doesn't seem to do anything other than scroll to the currently selected folder, and there's no help to be seen. "Collect images" keeps reverting the view to unordered "film roll", which is useless with a big collection. The devs refuse to add file handling code[1]. It's currently using 400+% CPU while not showing anything happening.
Free software and proprietary software have big incentive problems, but the problems are different:
In proprietary software, acting in a scummy way many times doesn't result in loss of profits, it may even increase profits.
Free software has the problem that usually there are no hierarchies and, consequently, no responsibilities. That makes it harder to imprint a coherent vision on a project. It also makes it harder for non-software people (graphic designers et al) to join, since complex cross-discipline ventures require a lot of organization and structure. QA, writing docs and other "boring" jobs become an afterthought.
I think the way to fix this is making free software organizations akin to commercial entities in their internal organization: have bosses and pay salaries, but still be non-profits so that the incentive to be scummy is small. The source of income being, obviously, donations.
In 2020, you can learn enough about programming in a 6 week bootcamp to be an effectively contributor at many companies. I'm not sure it was so easy in 1995. That said, I think the variability of free software has greatly expanded. There's piles and piles of poorly written garbage in package repositories now like npm, pypi, maven, rubygems, etc since it's so easy to publish code.
I think it's also worth noting a lot of popular OSS and FSF still has massive commercial interests backing it. Maybe Linux is free but that doesn't change all the huge companies pouring massive amounts of money into it (Microsoft, Google, Amazon, IBM, etc)
When this article was created, there was hardly a concept of SaaS like there is now but look how popular Github is vs Gitlab
I remember being impressed by this article when it came out, but while this metric (about bugs found by fuzzing) is appealing, it's confounded by a lot of other factors—like development environment and language, coding standards, whether the project is regularly doing its own fuzz testing, whether the project makes effective use of high quality libraries, whether people who wrote important parts of the logic are super-sticklers for taking particular precautions...
In particular, one development that way postdates this study is that lots of software projects started doing their own automated fuzz testing (but lots of others didn't). There are free software projects that don't do this, and there are proprietary software projects that do, and vice versa.
A particular shock for people like me who had internalized this and also ESR's "many eyeballs make bugs shallow" and also the same-day Linux kernel patch for the Ping of Death was that Microsoft started spending a billion dollars a year or whatever on improving Windows code quality and security around 2007—and it actually worked! Also now Microsoft Research people are doing a lot of formal methods stuff (although I don't know how much their work influences Microsoft's software products).
My personal experience has been different. Windows has been reasonably reliable since, oh, Win2k pro or so. These days, I never encounter full OS freezes or crashes, but I do encounter them occasionally at work, using Linux.
>They tested seven commercial Unix systems as well as GNU. By subjecting them to a random input stream, they could “crash (with core dump) or hang (infinite loop) over 40% (in the worst case) of the basic utility programs…”
As an end user, the least thing I care about is how the program behaves under some synthetic circumstances that I will very likely never encounter.
The thing I care the most is how much effort (physical time and also distraction) does it take to solve my typical workday problems with certain software. And, based on my experience, GNU tools very rarely excel at this metric.
I even have a fairly good assumption on why this is the case. Making software that works intuitively for most of your end users is a painstaking process. You need to research your market, document and prioritize use cases, run tests, update documentation, listen to feedback, quantify and prioritize it, provide support to your users. Then a thing or two changes about the "typical" workflow, or another OS version comes out, or some library you have been using gets broken, and you're out of tens of hours to fix it. And after you're done, the end user will install an update and think "nah, nothing changed, why did I bother updating?". You've freed your end users from mind-numbing grind by grinding it yourself for them.
You're not gonna be doing that unless that software is bringing in enough money to justify the hassle. There are numerous much more pleasant things to do in one's free time.
What free software is good at is proof-of-concept solutions. Someone looked at a tough problem and spent some evenings making an elegant solution. Or got some cool idea that might work and demonstrated that it does under one set of circumstances. Or implemented a cool algorithm from a research paper. It is a mentally rewarding thing and many people would do it for fun. But in most of the cases it's not enough to make a great end-user product.
> What free software is good at is proof-of-concept solutions. Someone looked at a tough problem and spent some evenings making an elegant solution.
That's pretty dismissive of gcc, clang, linux, apache etc. "some evenings", eh? By 2000 I'd put probably $60M into gcc alone.
> The thing I care the most is how much effort (physical time and also distraction) does it take to solve my typical workday problems with certain software. And, based on my experience, GNU tools very rarely excel at this metric.
Whereas based on my experience it excels, in particular over software that only, or primarily works with a GUI.
The GNU tools in particular are optimized for their target end-user base.
You may happen not to be in it. Nothing bad or good about that; there's plenty of stuff for which I am not in the target user base. It just seems odd you are so casually dismissive.
> As an end user, the least thing I care about is how the program behaves under some synthetic circumstances [fuzz test] that I will very likely never encounter.
Actually you care a lot that your program is robust against fizz tests like these, for security and accident reasons... or you will care if it has not been subject to such tests. Just as you care that your car has been crash tested "under some synthetic circumstances"
> The GNU tools in particular are optimized for their target end-user base.
Yeah, I'm thinking maybe you didn't use MetroWerks CodeWarrior or Borland C++ back in the day.
Those IDEs could scream through compiling a C++ code base, and provided superb integration between the compiler, editor, and debugger.
Gcc by comparison is slow, and the tooling is still stone knives and bearskins compared to what Windows and Mac users had in the 90s.
So either the target end user base is people who don't mind slow compilers and poorly integrated tools (maybe understandable in the embedded world where it's that or nothing for some arcane CPU architecture), or the GNU tools are poorly optimized.
You're not comparing apples to apples. Compare gcc or clang to Microsoft's C++ compiler from 2020, and you'll find that they're doing just fine. What's changed is that rather than a compiler that takes C++ in and produces x86 executable output, we have compiler suites that take input from C/C++/Fortran/whatever, runs it through a few decades' worth of optimizations, and then target the result at Linux/*BSD/NT/Darwin on ARM/x86/POWER/RISC-V/SPARC/MIPS. And optimizations are expensive.
>That's pretty dismissive of gcc, clang, linux, apache etc. "some evenings", eh? By 2000 I'd put probably $60M into gcc alone.
You mean the tools that are maintained by huge teams in large companies, because the they are critical to the paid products or services sold by these companies? Sure, technically it's free software, but de-facto they are decentralized loss leaders behind fairly solid business models.
>It just seems odd you are so casually dismissive.
I'm just talking about my own expectations and experience. Aside from a few notable exceptions like the ones you mentioned, my experience with free software very often starts with googling why it doesn't work out-of-the-box (or does something completely unintended) and where to find some obscure setting to change this.
> Just as you care that your car has been crash tested "under some synthetic circumstances"
I care that my car has been crash tested, but I don't care if my coffee mug wasn't. There are many solid cases where security is a priority, and many others where it isn't.
> You mean the tools that are maintained by huge teams in large companies, because the they are critical to the paid products or services sold by these companies? Sure, technically it's free software, but de-facto they are decentralized loss leaders behind fairly solid business models.
I mean, yeah, if you conveniently redefine FOSS as "software that never has any money put into it and is never allowed to have commercial backers" then it's gonna suck.
The basic difference is that free software is made by people who strive to write perfect software, while non-free software is made by people who strive to continue receiving a wire transfer at the end of the month by people who strive to be authorized to charge credit cards.
Open source contributor / maintainer here: I don't strive to write perfect software, I strive to use software to satisfy my constraints.
Software is tool to be used, not a holy artifact that should be polished for its own sake. The time I've spent working on software is only a proxy for the things I really care about.
- Sometimes I need to pay rent, and will work for projects that are a net positive when compared to the status quo.
- The rest of the time I'll volunteer my software engineering skills on projects that are closest to my ideals. These rarely generate revenue, but push the envelope a bit and help me develop relationships with other like-minded folks.
I think this has something to do with the sense of ownership behind the software.
An open source software is owned (literally and figuratively) by the people writing it, hence they will take care of it as they take care of their own.
On the other hand, propitary software is owned by some company (and its stockholders); it is written by employees payed to do so.
The employees will come and go, only the company will remain; naturally this reduces the sense of ownership any programmer may have over the code and with it, the quality of the software.
this is, of course, a very broad generalization riddled with exceptions and special cases. Not all software is alike.
Its often cheaper to hire a few devs to work on opensource projects your company relies on than pay for some proprietary software. Also allows you to retain control too.
I suspect much of it has to do with the number of unexpected scenarios that widely deployed free software encounters. It doesn’t cost anything and any random person within an organization can figure out how to get it running and try it out (and submit patches/big reports/etc). Whereas most commercial software sees relatively few different deployment scenarios since they were built and bought to a smaller set of things.
Much bigger one is not being at the mercy of whatever latest price change/monetization drive bus the commercial side is trying to throw the consumer under
I don't know whether free software is more reliable than proprietary software (I certainly hope it is, since I've been a daily Linux user for almost a decade now), but I do know GNU software in particular is not reliable in absolute terms: many GNU projects are popular punching bags for evaluating fuzzers, and have been for years because the bugs never get fixed.
I'm not at all surprised. With free software, everyone knows who contributed what to the project. If it's lousy work, your name is attached to it. If it is great work, your name is attached to it. There are powerful reasons to do good work.
For closed source, however, nobody outside the company knows what your contribution actually is, so there is less incentive.
This is a pretty weak argument and one that is obviously biased from the start given the source.
I'm generally pretty hard on most software being much less reliable than you'd think or want it to be, close or open source.
But in my personal experience, I've had plenty of closed source, proprietary software bugs fixed by the company that makes the software. In fact, I'd say the great majority of bugs were fixed if not all. I've never had a bug fixed in open source software I've submitted bugs for, and I've even had trouble getting them even assessed as bugs in the first place.
> But in my personal experience, I've had plenty of closed source, proprietary software bugs fixed by the company that makes the software. In fact, I'd say the great majority of bugs were fixed if not all. I've never had a bug fixed in open source software I've submitted bugs for, and I've even had trouble getting them even assessed as bugs in the first place.
Did you pay them as much as you paid for proprietary software?
Is that a fair argument? I thought the argument made in the article is that free software is more reliable. I do not want to pay a la carte for bug fixes and feature requests, and I definitely don't want to go through the processes required to do so. Even if I did, then that is no longer free software, is it?
If someone wants to charge for a bundled or packaged piece of software, then go for it. If it satisfies a need, is useful, and gets good support, then I have no problem paying for it or requesting for it to be purchased.
It's GNU; when they say free software, they mean "free as in freedom", not no-money-involved. You would not be the first person to find find this word choice... unhelpful.
reliable, but rarely ever use friendly. Usually the UI designs (if any) are done by a software developer which typically leads to UI layouts that are difficult for new users to learn. Command line interfaces are inherently not user friendly which is what almost all of GNU's software packages use.
I can see how popular free software can be more reliable since you have a critical mass that uses it regularly as well as can fix bugs as they come up. However, there's a bit of survivorship bias here. Free software that is unreliable may never reach critical mass in terms of user base as well as open source developers, i.e. a sort of "Great Filter" applied to FOSS
There is an opinion that commercial software often has more of the features desired by users, and also that free software is underfunded and often lags on development velocity
Not the OP, but using comparisons of 1995 software to try and make a point about the current software situation is some indication that people making that argument are several decades behind. The software that we use in 2020 and need to be reliable in 2020 is quite different than 25 years ago, heck, the platforms running the software are quite different - in 1995 you'd be using some program running on an OS on your computer (or through a remote terminal on some other computer); in 2020 you'd be using some program running on a distributed set of cloud servers through a browser sandbox - and the way how the reliability of that remote system is maintained is simply different from how you'd ensure the reliability of a local utility program. That 1995 study is perhaps interesting enough to suggest doing some experiments again, but currently it's outdated enough to be simply irrelevant.
All of the reasons they give for free software (or more specifically mentioned in the article, "gnu software") apply to good ol' open source software too (which is free as in free of FSF dogma & rms).
Let's look at the reasons:
> free software gets the whole community involved in working together to fix problems.
> developers really care about reliability
> an author who makes the source code available for all to see puts his reputation on the line, and had better make the software clean and clear, on pain of the community's disapproval.
The injection of [GNU/] in the quote is pretty funny too.
>an author who makes the source code available for all to see puts his reputation on the line, and had better make the software clean and clear, on pain of the community's disapproval
I've produced clean, well documented, 100% tested code, with examples, and have been met with disapproval from the redditor community. Some complaints,
>Someone already did that.
Mine is better in some way.
>The scope of your project is too big/small.
Okay Goldilocks.
>You wrote it in language x and I need something in y
Yeah, sorry for your loss buddy.
>Your language choice doesn't allow for some language feature that would make this easier to use
I look forward to seeing your implementation in that language then.
I give zero fucks about community disapproval when I am already giving away my work for free. If anything, the community is likely to steer me away from making more contributions, because when you're Billy the Kid, everyone is trying to shoot you in the back for the cred.
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.
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.
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.
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.
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.
Free software ≠ non-commercial software
That’s a false dichotomy.
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.
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.
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.
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.
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.
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.
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.
> 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 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.
In modern times, that statement still holds.
In the sense that you don't risk losing everything if the company providing the software (often as service) goes under, stops development or simply decides to "pivot" their product into something else.
You can build, maintain and host it all yourself.
If the service is at all useful, some other provider will enter to fill the void. You should never trust any service which doesn’t allow you to download your data, OSS-backed or not.
"The market can remain irrational longer than your runway"
Dealing with this now with SourceTree. Development is completely dead.
I don't want to use a new tool. I just want to fix a couple bugs. I'd do it myself if the application were open source...
Had the same issue, picked up fork and it seems to be the closest of any alternative i've tried. https://fork.dev
Lately I've been using sublime merge, works pretty well.
Free Software is amazing. I love emacs, Firefox, bash, zsh, nginx, postgres, llvm, linux, freebsd, and many other packages. But, I think that there are two points to be made with regard to commercial software.
1: Domain specific programs, and polish. Logic Pro X, Final Cut Pro X, Ableton, Cubase, Premier Pro, are are excellent pieces of software that people pay for and use every day. Where is the free software equivalent that isn't glitchy and has a usable, slick, ui? The more specific the case gets, and the less related to systems a Free Software project is, the less likely it is to exist or have any polish. I can list Postgres, Redis, Linux, OpenBSD, NetBSD, NodeJS, WebKit, SpiderMonkey, LLVM, GCC, Binutils, Busybox, etc., but where is the free software iMessage, Google Docs, Discord, iTunes, Steam, Google Maps, etc. There may be some of these projects out there for what I just listed, but none of them have a userbase as big as that proprietary software. The only things I can think of are VLC, Blender, and Android.
2: Free Software can only exist with Commercial Software. How many people that work in Free Software are software engineers working at a corporation? What pays for this Free Software to exist? Microsoft hosts github, big enough Free Software projects have budgets and employees at other companies paying for all of it.
With all due respect to the author here, the arguments presented aren't particularly compelling.
> Apologists for proprietary software like to say, “free software is a nice dream, but we all know that only the proprietary system can produce reliable products. A bunch of hackers just can't do this.”
Absolutely no one says this anymore. In 2014, when the article was written, almost no one would say it.
> Barton P. Miller and his colleagues tested the reliability of Unix utility programs in 1990 and 1995. Each time, GNU's utilities came out considerably ahead.
That's great, but it's 2020 now.
The FSF has done awesome work, but they might be better served presenting modern research and evidence about the reliability of free software.
That was exactly how I felt too. The examples given were laughable. I get that those are simple programs and it's easier to test them, but if you can't test the bigger/harder stuff easily, how can you make a claim as to which is better?
> In 2014, when the article was written
The original version was written in 1997: https://web.archive.org/web/19980126190044/http://www.gnu.or...
Pages like these should still be kept up to date, of course.
>Absolutely no one says this anymore. In 2014, when the article was written, almost no one would say it.
The sentiment is echoed multiple times in this thread, maybe shifted a bit to account for the clear examples of success available today.
Free utilities with well-defined success criteria (cat, tac, head, tail, ls, rm, cd, etc.) are generally rock solid. And there are some examples of excellent desktop software (Firefox, KeePass.?.?, GNOME Terminal). However, many GUI applications have the kind of decade-old bugs and UX which means I really can't recommend any of them, and I only use them because I don't trust the intentions of their closed source equivalents.
- Calc seems to have fewer graphing options and mathematical functions than the last Excel I used back in 2009.
- Thunderbird keeps randomly losing emails when dragging and dropping things between folders, and incoming email filters only work some of the time.
- GNOME Evolution doesn't seem to be able to save draft emails while offline, so I just have to hope that I get online to send it before GNOME desktop has one of its moments. Weekly recurring calendar entries seem to be split up into daily recurring ones in recent versions. Search is interminably slow compared to any other client, including Thunderbird.
- Darktable has absolutely oodles of features, but I can't tell what anything does except by trial and error. F1 doesn't seem to do anything other than scroll to the currently selected folder, and there's no help to be seen. "Collect images" keeps reverting the view to unordered "film roll", which is useless with a big collection. The devs refuse to add file handling code[1]. It's currently using 400+% CPU while not showing anything happening.
[1] https://www.darktable.org/about/faq/#faq-rename-files
Free software and proprietary software have big incentive problems, but the problems are different:
In proprietary software, acting in a scummy way many times doesn't result in loss of profits, it may even increase profits.
Free software has the problem that usually there are no hierarchies and, consequently, no responsibilities. That makes it harder to imprint a coherent vision on a project. It also makes it harder for non-software people (graphic designers et al) to join, since complex cross-discipline ventures require a lot of organization and structure. QA, writing docs and other "boring" jobs become an afterthought.
I think the way to fix this is making free software organizations akin to commercial entities in their internal organization: have bosses and pay salaries, but still be non-profits so that the incentive to be scummy is small. The source of income being, obviously, donations.
In 2020, you can learn enough about programming in a 6 week bootcamp to be an effectively contributor at many companies. I'm not sure it was so easy in 1995. That said, I think the variability of free software has greatly expanded. There's piles and piles of poorly written garbage in package repositories now like npm, pypi, maven, rubygems, etc since it's so easy to publish code.
I think it's also worth noting a lot of popular OSS and FSF still has massive commercial interests backing it. Maybe Linux is free but that doesn't change all the huge companies pouring massive amounts of money into it (Microsoft, Google, Amazon, IBM, etc)
When this article was created, there was hardly a concept of SaaS like there is now but look how popular Github is vs Gitlab
I remember being impressed by this article when it came out, but while this metric (about bugs found by fuzzing) is appealing, it's confounded by a lot of other factors—like development environment and language, coding standards, whether the project is regularly doing its own fuzz testing, whether the project makes effective use of high quality libraries, whether people who wrote important parts of the logic are super-sticklers for taking particular precautions...
In particular, one development that way postdates this study is that lots of software projects started doing their own automated fuzz testing (but lots of others didn't). There are free software projects that don't do this, and there are proprietary software projects that do, and vice versa.
A particular shock for people like me who had internalized this and also ESR's "many eyeballs make bugs shallow" and also the same-day Linux kernel patch for the Ping of Death was that Microsoft started spending a billion dollars a year or whatever on improving Windows code quality and security around 2007—and it actually worked! Also now Microsoft Research people are doing a lot of formal methods stuff (although I don't know how much their work influences Microsoft's software products).
I think factors other than whether software is free or proprietary are now dominating for their influence on code quality metrics. (See also https://mako.cc/writing/hill-when_free_software_isnt_better....)
My personal experience has been different. Windows has been reasonably reliable since, oh, Win2k pro or so. These days, I never encounter full OS freezes or crashes, but I do encounter them occasionally at work, using Linux.
Couldn't help but giggle at the inserted [GNU/] in that quote.
The correct URL is: gnu-https://gnu-www.gnu.gnu-org/gnu/software/gnu/reliability.gnu...
>They tested seven commercial Unix systems as well as GNU. By subjecting them to a random input stream, they could “crash (with core dump) or hang (infinite loop) over 40% (in the worst case) of the basic utility programs…”
As an end user, the least thing I care about is how the program behaves under some synthetic circumstances that I will very likely never encounter.
The thing I care the most is how much effort (physical time and also distraction) does it take to solve my typical workday problems with certain software. And, based on my experience, GNU tools very rarely excel at this metric.
I even have a fairly good assumption on why this is the case. Making software that works intuitively for most of your end users is a painstaking process. You need to research your market, document and prioritize use cases, run tests, update documentation, listen to feedback, quantify and prioritize it, provide support to your users. Then a thing or two changes about the "typical" workflow, or another OS version comes out, or some library you have been using gets broken, and you're out of tens of hours to fix it. And after you're done, the end user will install an update and think "nah, nothing changed, why did I bother updating?". You've freed your end users from mind-numbing grind by grinding it yourself for them.
You're not gonna be doing that unless that software is bringing in enough money to justify the hassle. There are numerous much more pleasant things to do in one's free time.
What free software is good at is proof-of-concept solutions. Someone looked at a tough problem and spent some evenings making an elegant solution. Or got some cool idea that might work and demonstrated that it does under one set of circumstances. Or implemented a cool algorithm from a research paper. It is a mentally rewarding thing and many people would do it for fun. But in most of the cases it's not enough to make a great end-user product.
> What free software is good at is proof-of-concept solutions. Someone looked at a tough problem and spent some evenings making an elegant solution.
That's pretty dismissive of gcc, clang, linux, apache etc. "some evenings", eh? By 2000 I'd put probably $60M into gcc alone.
> The thing I care the most is how much effort (physical time and also distraction) does it take to solve my typical workday problems with certain software. And, based on my experience, GNU tools very rarely excel at this metric.
Whereas based on my experience it excels, in particular over software that only, or primarily works with a GUI.
The GNU tools in particular are optimized for their target end-user base.
You may happen not to be in it. Nothing bad or good about that; there's plenty of stuff for which I am not in the target user base. It just seems odd you are so casually dismissive.
> As an end user, the least thing I care about is how the program behaves under some synthetic circumstances [fuzz test] that I will very likely never encounter.
Actually you care a lot that your program is robust against fizz tests like these, for security and accident reasons... or you will care if it has not been subject to such tests. Just as you care that your car has been crash tested "under some synthetic circumstances"
> The GNU tools in particular are optimized for their target end-user base.
Yeah, I'm thinking maybe you didn't use MetroWerks CodeWarrior or Borland C++ back in the day.
Those IDEs could scream through compiling a C++ code base, and provided superb integration between the compiler, editor, and debugger.
Gcc by comparison is slow, and the tooling is still stone knives and bearskins compared to what Windows and Mac users had in the 90s.
So either the target end user base is people who don't mind slow compilers and poorly integrated tools (maybe understandable in the embedded world where it's that or nothing for some arcane CPU architecture), or the GNU tools are poorly optimized.
You're not comparing apples to apples. Compare gcc or clang to Microsoft's C++ compiler from 2020, and you'll find that they're doing just fine. What's changed is that rather than a compiler that takes C++ in and produces x86 executable output, we have compiler suites that take input from C/C++/Fortran/whatever, runs it through a few decades' worth of optimizations, and then target the result at Linux/*BSD/NT/Darwin on ARM/x86/POWER/RISC-V/SPARC/MIPS. And optimizations are expensive.
>That's pretty dismissive of gcc, clang, linux, apache etc. "some evenings", eh? By 2000 I'd put probably $60M into gcc alone.
You mean the tools that are maintained by huge teams in large companies, because the they are critical to the paid products or services sold by these companies? Sure, technically it's free software, but de-facto they are decentralized loss leaders behind fairly solid business models.
>It just seems odd you are so casually dismissive. I'm just talking about my own expectations and experience. Aside from a few notable exceptions like the ones you mentioned, my experience with free software very often starts with googling why it doesn't work out-of-the-box (or does something completely unintended) and where to find some obscure setting to change this.
> Just as you care that your car has been crash tested "under some synthetic circumstances" I care that my car has been crash tested, but I don't care if my coffee mug wasn't. There are many solid cases where security is a priority, and many others where it isn't.
> You mean the tools that are maintained by huge teams in large companies, because the they are critical to the paid products or services sold by these companies? Sure, technically it's free software, but de-facto they are decentralized loss leaders behind fairly solid business models.
I mean, yeah, if you conveniently redefine FOSS as "software that never has any money put into it and is never allowed to have commercial backers" then it's gonna suck.
The basic difference is that free software is made by people who strive to write perfect software, while non-free software is made by people who strive to continue receiving a wire transfer at the end of the month by people who strive to be authorized to charge credit cards.
Open source contributor / maintainer here: I don't strive to write perfect software, I strive to use software to satisfy my constraints.
Software is tool to be used, not a holy artifact that should be polished for its own sake. The time I've spent working on software is only a proxy for the things I really care about.
- Sometimes I need to pay rent, and will work for projects that are a net positive when compared to the status quo.
- The rest of the time I'll volunteer my software engineering skills on projects that are closest to my ideals. These rarely generate revenue, but push the envelope a bit and help me develop relationships with other like-minded folks.
Having your name tied to your publically available code is a strong insentive to make it look good
I think this has something to do with the sense of ownership behind the software.
An open source software is owned (literally and figuratively) by the people writing it, hence they will take care of it as they take care of their own.
On the other hand, propitary software is owned by some company (and its stockholders); it is written by employees payed to do so.
The employees will come and go, only the company will remain; naturally this reduces the sense of ownership any programmer may have over the code and with it, the quality of the software.
this is, of course, a very broad generalization riddled with exceptions and special cases. Not all software is alike.
Its often cheaper to hire a few devs to work on opensource projects your company relies on than pay for some proprietary software. Also allows you to retain control too.
I suspect much of it has to do with the number of unexpected scenarios that widely deployed free software encounters. It doesn’t cost anything and any random person within an organization can figure out how to get it running and try it out (and submit patches/big reports/etc). Whereas most commercial software sees relatively few different deployment scenarios since they were built and bought to a smaller set of things.
Maybe. It’s almost a non factor for me though.
Much bigger one is not being at the mercy of whatever latest price change/monetization drive bus the commercial side is trying to throw the consumer under
"Commercial" versus "Free Software"? Really?
RedHat has been providing commercial Free Software for a long time now. And an excellent job they make of it too.
I don't know whether free software is more reliable than proprietary software (I certainly hope it is, since I've been a daily Linux user for almost a decade now), but I do know GNU software in particular is not reliable in absolute terms: many GNU projects are popular punching bags for evaluating fuzzers, and have been for years because the bugs never get fixed.
I'm not at all surprised. With free software, everyone knows who contributed what to the project. If it's lousy work, your name is attached to it. If it is great work, your name is attached to it. There are powerful reasons to do good work.
For closed source, however, nobody outside the company knows what your contribution actually is, so there is less incentive.
This is a pretty weak argument and one that is obviously biased from the start given the source.
I'm generally pretty hard on most software being much less reliable than you'd think or want it to be, close or open source.
But in my personal experience, I've had plenty of closed source, proprietary software bugs fixed by the company that makes the software. In fact, I'd say the great majority of bugs were fixed if not all. I've never had a bug fixed in open source software I've submitted bugs for, and I've even had trouble getting them even assessed as bugs in the first place.
> But in my personal experience, I've had plenty of closed source, proprietary software bugs fixed by the company that makes the software. In fact, I'd say the great majority of bugs were fixed if not all. I've never had a bug fixed in open source software I've submitted bugs for, and I've even had trouble getting them even assessed as bugs in the first place.
Did you pay them as much as you paid for proprietary software?
Is that a fair argument? I thought the argument made in the article is that free software is more reliable. I do not want to pay a la carte for bug fixes and feature requests, and I definitely don't want to go through the processes required to do so. Even if I did, then that is no longer free software, is it?
If someone wants to charge for a bundled or packaged piece of software, then go for it. If it satisfies a need, is useful, and gets good support, then I have no problem paying for it or requesting for it to be purchased.
It's GNU; when they say free software, they mean "free as in freedom", not no-money-involved. You would not be the first person to find find this word choice... unhelpful.
My mistake for conflating the two. I am aware of the difference but lost track. However, they are often correlated.
I find two things to be true and a desire to have both or at least balance them:
Free software is usually more reliable.
Commercial software usually has better UX.
reliable, but rarely ever use friendly. Usually the UI designs (if any) are done by a software developer which typically leads to UI layouts that are difficult for new users to learn. Command line interfaces are inherently not user friendly which is what almost all of GNU's software packages use.
My experience upgrading Ubuntu and Arch installations says otherwise. I gave up years ago and always do a clean install now.
...you do a clean install of a rolling release distro rather than updating it in place? How does that work?
I can see how popular free software can be more reliable since you have a critical mass that uses it regularly as well as can fix bugs as they come up. However, there's a bit of survivorship bias here. Free software that is unreliable may never reach critical mass in terms of user base as well as open source developers, i.e. a sort of "Great Filter" applied to FOSS
The exact opposite is generally true.
So back in 1990 and 1995, they compared GNU utilities to commercial utilities?
And this is the proof that "free software" is more reliable???
Is it also proof that "free software" is several decades behind?
> Is it also proof that "free software" is several decades behind?
Not sure what you mean by this, could you elaborate?
There is an opinion that commercial software often has more of the features desired by users, and also that free software is underfunded and often lags on development velocity
Not the OP, but using comparisons of 1995 software to try and make a point about the current software situation is some indication that people making that argument are several decades behind. The software that we use in 2020 and need to be reliable in 2020 is quite different than 25 years ago, heck, the platforms running the software are quite different - in 1995 you'd be using some program running on an OS on your computer (or through a remote terminal on some other computer); in 2020 you'd be using some program running on a distributed set of cloud servers through a browser sandbox - and the way how the reliability of that remote system is maintained is simply different from how you'd ensure the reliability of a local utility program. That 1995 study is perhaps interesting enough to suggest doing some experiments again, but currently it's outdated enough to be simply irrelevant.
It's a notable and interesting look back in time. That's when I was just getting started with opensource software.
Counter-examples: Printing, 3d acceleration, Sound.
Also package hell. I'll just update this one thing ... 16 hours later you're at kernel level.
I don't know, no broad brush statement works here.
This seems to be more “Linux is more reliable” rather than free software in general is more reliable.
I suspect this would hold less true as maintainers became fewer and far between and resources became less available.
All of the reasons they give for free software (or more specifically mentioned in the article, "gnu software") apply to good ol' open source software too (which is free as in free of FSF dogma & rms).
Let's look at the reasons:
> free software gets the whole community involved in working together to fix problems.
> developers really care about reliability
> an author who makes the source code available for all to see puts his reputation on the line, and had better make the software clean and clear, on pain of the community's disapproval.
The injection of [GNU/] in the quote is pretty funny too.
>an author who makes the source code available for all to see puts his reputation on the line, and had better make the software clean and clear, on pain of the community's disapproval
I've produced clean, well documented, 100% tested code, with examples, and have been met with disapproval from the redditor community. Some complaints,
>Someone already did that.
Mine is better in some way.
>The scope of your project is too big/small.
Okay Goldilocks.
>You wrote it in language x and I need something in y
Yeah, sorry for your loss buddy.
>Your language choice doesn't allow for some language feature that would make this easier to use
I look forward to seeing your implementation in that language then.
I give zero fucks about community disapproval when I am already giving away my work for free. If anything, the community is likely to steer me away from making more contributions, because when you're Billy the Kid, everyone is trying to shoot you in the back for the cred.
This is why I've stopped working on free software.
Yes, the minority ruin it for the majority, but the majority, at the end of the day, don't have to read my inbox.