There is a common theme pushed by fanatics of capitalism that never dies: that a profit-driven commercial project ensures higher quality products than products under non-profit projects. Some hard-right people I know never miss the chance to use the phrase “good enough for government work” to convey this idea.
I’m not looking to preach to the choir here, but rather to establish a thread of scenarios that correspond to quality for the purpose of countering inaccurate narratives. This is the thread to share your stories.
In my day job I’m paid to write code. Then I go home write code I was not paid for. My best work is done without pay.
Commercial software development
When I have to satisfy an employer, they don’t want quality code. They want fast code. They want band-aid fixes. The corporate structure is too myopic to optimize for quality.
Anti-gold-plating:
I was once back-roomed by a manager and lectured for “gold plating”. That means I was producing code that was higher quality than what management perceives as economically optimal.
Bug fixes hindered:
I was caught fixing some bugs conveniently as I spotted them when I happened to have a piece of code checked out in Clearcase. I was told I was “cheating the company out of profits” because they prefer if the bugs each go through a documentation procedure so the customer can ultimately be made to pay separately for the bug fix. Nevermind the fact that my time was already charged anyway (but they can get more money if there’s a bigger paper trail involving more staff). This contrasts with the “you get what you pay for” narrative since money is diverted to busy work (IOW: working hard, not smart).
Bugs added for “consistent quality”:
One employer was so insistent on “consistent quality” that when one module was higher quality than another, they insisted on lowering the quality of the better module because improving the style or design pattern of the lower quality piece would be “gold plating”. This meant injecting bugs to achieve consistency. The bugs were non-serious varieties; more along the lines of needless complexity, reduced performance, coding standard non-compliances, etc, but nonetheless something that could potentially be charged to the customer to fix.
Syntactic dumbing-down:
When making full use of the language constructs (as intended by the language designers), I am often forced by an employer to use a more basic subset of constructs. Employers are concerned that junior engineers or early senior engineers who might have to maintain my code will encounter language constructs that are less common and it will slow them down to have to look up the syntax they encounter. Managers assume that future devs will not fully know the language they are working in. IMO employers under-estimate the value of developers learning on the job. So I am often forced avoid using the more advanced constructs to accommodate some subset of perceived lowest common denominator. E.g. if I were to use an array in bash, an employer might object because some bash maintainers may not be familiar with an array.
Non-commercial software development
Free software developers have zero schedule pressure. They are not forced to haphazardly rush some sloppy work into an integration in order to meet a deadline that was promised to a customer by a manager who was pressured to give an overly optimistic timeline due to a competitive bidding process. #FOSS devs are free to gold-plate all they want. And because it’s a labor of love and not labor for a paycheck, FOSS devs naturally take more pride in their work.
I’m often not proud of the commercial software I was forced to write by a corporation fixated on the bottom line. When I’m consistently pressured to write poor quality code for a profit-driven project, I hit a breaking point and leave the company. I’ve left 3 employers for this reason.
Commercial software from a user PoV
Whenever I encounter a bug in commercial software there is almost never a publicly accessible bug tracker and it’s rare that the vendor has the slightest interest in passing along my bug report to the devs. The devs are unreachable by design (cost!). I’m just one user so my UX is unimportant. Obviously when I cannot even communicate a bug to a commercial vendor, I am wholly at the mercy of their testers eventually rediscovering the same bug I found, which is unlikely in complex circumstances.
Non-commercial software from a user PoV
Almost every FOSS app has a bug tracker, forum, or IRC channel where bugs can be reported and treated. I once wrote a feature request whereby the unpaid FOSS developer implemented my feature request and sent me a patch the same day I reported it. It was the best service I ever encountered and certainly impossible in the COTS software world for anyone who is not a multi-millionaire.
Anyone who says paid software is guaranteed to be better is either selling you something or delusional.
FOSS has almost never disappointed me as an end user. Windows disappoints me every time I use it.
Commercial software: complete goals x, y, and z and get paid.
FOSS: Project of passion.
Short and black and white version: I’d rather use the software people are excited to make.
My take on what’s realistic: Things are rarely so simple. Commercial software will often (not always) be easier to use. I feel like most users don’t want to expend any more than minimal effort to effectively use their software (which I don’t think is unreasonable). So in those cases and for those users, easier = better.
Also, highly specialized commercial software might be better than any FOSS options. For example, there’s nothing in the FOSS world that can compete with the big players in commercial electronic medical records software.
So, while I love FOSS, and I find Capitalism problematic, sometimes commercial is better.
P.S: The response is more to the concept of the post. Your actual post is both well written and thought out and doesn’t feel at all like “black and white” thinking.
Great example: FOSS CAD.
It takes massive investment to build the systems you see in things like Catia/SolidWorks/Autodesk. Where’s the FOSS CAD that competes with these?
Another massive difference is ownership and risk offloading. Enterprise buys commercial software and pays contracts for maintenance to offload the risk of the software and maintenance activities. I’m sure damn few FOSS devs are capable of playing in that world, where millions of dollars can be lost due to a software failure by a vendor - and since that vendor has been contracted to supply a given Service Level, they pay for the Enterprise loss (well, their insurance does).
This post is as simplistic as the people who claim paid software or FOSS is always better.
Everything has it’s place, but I doubt I’m recommending FOSS for anything requested by management - nothing fits the requirements from a B2B perspective. There may be a few out there, but the ones I’ve seen are niche operators who are really large companies themselves, using extant FOSS or even financially supporting an FOSS project (Syncthing comes to mind).
Ya… I’m with you 100%. It really feels like commercial software is the “minimum viable product” rather than a complete and quality piece of software. I’ve opted for FOSS solutions wherever possible for me and it has worked out swimmingly. Only place I’m still struggling is my home PC. Making the jump to Linux and potentially risking game compatibility is still a bit of a hurdle for me, but once my Win10 license loses support, Linux will be a very strong contender for my main OS.
It wasn’t always like this. Back before companies understood “minimum viable product” things were better. Now companies do the “minimum” and then never come back to finish what they started because they can’t see a profit in it. It’s obvious in the way Microsoft has been replacing the old, working parts of the OS with new parts that look more modern but don’t work as well, and rarely improving the replacements to reach parity with what was replaced.
I’ve been out of the loop on games for a while but ReactOS may be worth a look.
Now deploy those solutions to a business, where measurable uptime is a requirement, and you lose money (as in money you would be paid for your work is canceled) because you missed those metrics.
Or worse, there’s an outage, and your client can’t do their work for a day. Again, you’ll be paying for their lost business, because contracts are written to offload that risk to you, the supplier of a solution.
Yea, this stuff is great, and can work well where risks are low, or not contractually offloaded. Say for your own company/small org that’s risk tolerant, and sees FOSS as an opportunity to build their infrastructure a specific way. This approach means always ensuring you have specific, and duplicated, Subject Matter Experts in-house for everything you bring in. Not just Bob. Because if Bob is the only SME, when he gets hit by a bus, you’ll be shit out of luck.
Even worse, most Enterprises work damn hard at documenting what they do, and doing what they document, and I’d bet at best they’re hitting 90% on most systems after initial setup.
SMB (where the FOSS argument is more compelling) doesn’t even try to document their systems (well, some, but nothing like what Enterprises do, and that’s not a criticism, they don’t usually have the flexibility in time or money to justify it).
In Enterprise, the person writing the docs never touches production - they typically develop their docs by working in a variety of test environments, those docs are then passed to teams that manage only production systems. This provides a division of responsibility, and ensures that if your Primary SME is hit by a bus, you’re not SOL because his backup would simply refresh their knowledge via the docs).
I’m not seeing SMB rationalizing multiple SME’s for systems.
There’s always been absolute fucktons of proprietary software that’s buggy garbage. At this point even corporations have conceded the superiority of our development model and have adopted it themselves (even longtime foes like Microsoft). Honestly, most of FOSS’s problems could be dealt with by having a tighter relationship with UI/UX designers since that’s usually the biggest pain point.
Well said- FOSS software is almost always better at accomplishing the task at hand, but because most FOSS devs aren’t also UX/UI developers, the software is often harder to just pick up and use for someone unfamilliar. I think that’s the main reason it sometimes has a perception of being “worse”.
But that’s a shitty employer that is just making software for profit. Like Oracle or IBM. They have a niche of masochistic customers who enjoy being nickel and dimed at all times.
There are other examples, like indie games are closed source software that are written with no pressure to do x, y or Z and are driven by passion. Same for other programs, I can see there are many “quality first, money second” examples
And also in Foss there are highly opinionated software where the devs completely ignore users, ban them from GitHub when they post issues, or continuously change the APIs without a valid reason so your plugins need a constant rework and it’s a mess to stay behind
The 1st ½ of your comment sounds accurate. But…
And also in Foss there are highly opinionated software where the devs completely ignore users, ban them from GitHub when they post issues,
Right, but to be clear non-free s/w is worse - you can’t even reach the devs, generally, and there is no public bug tracker. FOSS is an improvement in this regard because at least there is a reasonable nuclear option (forking). The nuclear option for non-free software is writing it yourself from scratch.
Right
I do security as my dayjob (more blue team stuff these days, but used to do pentesting in the past).
Software development normally comes down to a holy trinity of Speed/Cost/Quality. You can only pick two.
Commercial software has time/cost constraints so they often pick speed and cost over quality initially. FOSS software doesn’t need to “get to the market”, but also doesn’t have any money, so you often get cost/quality over speed.
However - in larger enterprises there’s so much more, you get the whole SDL maturity thing going - money is invested into raising the quality of the whole development lifecycle and you get things like code reviews, architects, product planning, external security testing etc. Things that cost time, money and resources.
FOSS software is generally going to be missing this, unless the project gets popular and picked up by some big megacorp that bankrolls the development (Google, IBM etc). Look at mission critical projects like OpenSSL that was (until Heartbleed) more or less one man project.
Commercial software also needs to invest in licensing, support, documentation, certifications, training and potentially integration partners. It’s a whole different playing field. FOSS has easier time, because it’s generally just pointing at the code and saying “well send a PR”.
Then you have the whole devops thing, where you might take FOSS software and build a whole commercial service around it.
And all of this is just generalizing of course, because unless we’re just comparing small programs, there’s really no way to do objective comparisons between “commercial” and “free” without writing a full 50 page thesis.
Commercial software getting QA, code review, testing, etc seems to only apply till that corp has market share dominance, then they dgaf. I’m indirectly involved with corporate enterprise level software. They big players now release garbage that has breaking changes, they don’t care because user base pays yearly licensing and can’t drop the paid license nor drop the software; so they live with users being the bug testers. And beaides that they use foss components for some functionality.
That all sounds accurate enough to me… but thought I should comment on this:
However - in larger enterprises there’s so much more, you get the whole SDL maturity thing going - money is invested into raising the quality of the whole development lifecycle and you get things like code reviews, architects, product planning, external security testing etc. Things that cost time, money and resources.
It should be mentioned that many see testing as a cost, but in fact testing is a cost savings. In most situations, you only spend some money on testing in order to dodge a bigger cost: customers getting burnt in a costly way that backfires on the supplier. Apart from safety-critical products, this is the only business justification to test. Yet when budgets get tightened, one of the first cuts many companies make is testing – which is foolish assuming they are doing testing right (in a way that saves money by catching bugs early).
Since the common/general case with FOSS projects is there is no income that’s attached to a quality expectation (thus testing generates no cost savings) - the users are part of the QA process as free labor, in effect :)
God have mercy for the poor souls that have to use Clearcase. In fact it sounds like you and I may work for the same organization.
I feel this take misses the picture a bit in terms of the strengths and weaknesses of FOSS vs commercial software. FOSS is great at building tools for common or popular problems, but starts to run into challenges in solving problems that are some combination of niche, unfun, too big, or too hard.
For example, I needed to export thousands of scheduled jobs off of an IBM mainframe and onto a different platform as part of switching to a COTS ERP. Should I task an internal team of developers to write a one off? Would any open source solution exist? There aren’t a ton of zOS open source projects out there, in part because there just aren’t a lot of zOS systems programmers out there. They’ve all been frozen in carbonate to solve the Y3K problem, lol. No, in this case I light a pile of money on fire and pay Computer Associates for their commercial tool which generated an XML file almost a million lines long (just the jobs and scheduling parameters/dependencies). And it just worked, insofar as any ERP migration just works.
Another factor is the time it can take for a FOSS project to mature. No one would try and say that Octave is a 1-1 replacement for Matlab. Indeed, it wasn’t until jupyter notebooks came along in Python that I felt I really had a good Matlab alternative, and even then, some less common packages don’t have a good FOSS alternative in Python. I still remember the first time getting some of the open source convex analysis packages going on Linux. It was a nightmare of dependencies and didn’t have all the capabilities of the commercial solutions, because that type of mathematical software development is really, really hard.
Additionally, commercial software is helpful at supplying services with ongoing costs. E.g., office 365 with OneDrive would require rolling my own NextCloud with libre office or something similar to get anywhere near the functionality I get from a family Microsoft 365 account out of the box.
I’m all for FOSS, but a tool is a tool, and sometimes commercial software fills needs that just aren’t going to realistically attract a developer community. However, my favorite client tools are usually open source and I like being able to pilfer the code for my own projects.
Edit: I also wanted to add that I did commercial software development at one point, and I got to solve some really difficult, deep technical issues. It may sound really lame, but the work I did on search optimization for a commercial tool was really rewarding. Taking something that lots of people had to use and improving the execution time of arbitrary queries from minutes to seconds was a blast and important to the org, and something I was able to take the time to get right. I’ve also just had to bang out some CRUD code too, so of course it varies, but not every commercial code outfit it terrible to work for. And the hardware and OS on tools like Palo Alto firewalls just wouldn’t get made through open source alone.
This post highlights some issues with the commercial software that are obvious to anyone who is working in the industry, but completely ignores issues of the open source software. Both good and bad software is being developed using each model. It’s pointless to compare them this way. Linus in his book provided more substantial arguments in favor of open source.
bash arrays
On the flip side, some FOSS maintainers will prefer not to use arrays because “it’s not POSIX compliant”
In general I agree with you. I find that most FOSS software is more polished than proprietary software, and it is generally more powerful.
However, I think that one problem that people somehow overlook in my opinion is that the financial side of the issue is also extremely important. I want more people to work on quality FOSS software, and I want it to become socially acceptable to work on FOSS as your main job. For that one thing is needed in my opinion: we as users of FOSS software need to give developers the financial incentives to work on what they love the whole time. In fact I want it to reach the point where immoral, non FOSS companies struggle to find developers because they’re all working on FOSS.
If you need to use software professionally or in a commercial product, then go commercial.
I have been trying to switch to using more open source lately. And I couldn’t notice how more than 90% of projects I Land on are abandonware . and the rest are so slowly moving you shouldn’t rely on the for anything where security matters.
Stick with Foss projects that have a non profit behind then or a strong community of devs behind them. With a leat dozens of commits a month.
