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.

  • 0xtero@beehaw.org
    link
    fedilink
    arrow-up
    7
    ·
    11 months ago

    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.

    • BCsven
      link
      fedilink
      arrow-up
      6
      ·
      11 months ago

      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.

    • soloActivist@links.hackliberty.orgOP
      link
      fedilink
      arrow-up
      5
      ·
      11 months ago

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