Closed-source software follies

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Jan 25, 2007.

  1. Here's an entertaining story
    <> about some of
    the antics that software companies get up to, such as buying up an absolute
    crap piece of software simply because of the prospect of getting income
    from its existing customers (who must have been trapped by vendor lock-in,
    otherwise they'd have gone if they had any sense).

    What's not explicitly stated in the article is that all the products were
    closed-source. It's hard to see anything like that happening in an
    open-source project--at least, not for long: after the community had had
    enough of laughing itself silly over the code, it would either junk it in
    favour of a rewrite, or dive in and fix it.
    Lawrence D'Oliveiro, Jan 25, 2007
    1. Advertisements

  2. Lawrence D'Oliveiro

    Cadae Guest

    Great story. The company clearly wasn't listening to its technical advisors,
    and paid the price.
    Quality of code is independent of which license scheme is used to distribute
    it, you can't assume closed-source = = bad and open-source = = good.

    For example look at this - one of the most important Linux library routines-
    malloc: If malloc doesn't work
    properly, it can bring down an entire system.
    Note the use of goto statements, and the length of the functions - this is
    an analysis and maintenance nightmare. Does it work ? - maybe. Is it well
    engineered and thus reliable ? No.
    It'd been in use for years, and no one in the open-source community "dived
    in and fixed it".
    Compare with the contemporary malloc.c library in Visual Studio - there's a
    huge qualitative gap in favour of the Microsoft code.

    Cadae, Jan 25, 2007
    1. Advertisements

  3. Lawrence D'Oliveiro

    thingy Guest

    Not unknown, in fact depressingly of the worst.......POS
    (point of sale) stuff I have come across, it was locked down so you
    could not upgrade the box hardware without a new key....the vendor's
    ex-support guy who bought the code from the company that went broke
    wanted an huge monthly fee for "support" and another huge fee for a new
    key....the retailer was over a barrel....hardly making any money but had
    to come up with silly fees.........

    This is one of the reasons I am so keen on FOSS....the end user has the
    code so can go to any other service company who supports that code and
    use them....companies have to compete on costs and the end
    user is not ass raped by greedy slaes ppl.


    thingy, Jan 25, 2007
  4. You _did_ notice that what you referenced was not the actual source of the
    Linux kernel memory allocator, but a patch dating from 1993, did you not?

    The current Linux kernel memory allocator is actually called kmalloc, and
    you'll find it defined here <>, in a
    lot cleaner and more maintainable fashion than the obsolete example you
    Lawrence D'Oliveiro, Jan 26, 2007
  5. Lawrence D'Oliveiro

    Cadae Guest

    That's the point - essentially the same code with the same poor coding
    practice remained in use from 91 with only minor patches through to at least
    And that was a critical part of Linux for years. No one "dived in and fixed
    it" as you claim happens to open-source code. Even when they did fix parts
    of it, as per the patch example, the important coding faults didn't get
    fixed. There's a wealth of similarly poor code in the open-source world I
    can point to - I've seen absolutely abominable open-source code ... and I've
    also seen very good open-source code. The same is true for "closed-source"
    Only after many years had passed did this essential bit of code get its
    long-overdue improvements.

    Cadae, Jan 26, 2007
  6. Surely it has already been fixed, has it not?

    If you saw "absolutely abominable" code, did you submit a fix?

    How would you *know that* if you cannot see the source code?
    Dianthus Mimulus, Jan 26, 2007
  7. So where is that code now?
    Lawrence D'Oliveiro, Jan 26, 2007
  8. Lawrence D'Oliveiro

    Cadae Guest

    Yes - but it took years before it was fixed. No one dived in and fixed the
    bad coding ( as you claim happens ) even tho it was in a super-critical part
    of the linux code.
    Way too much bad code around to fix - and why should I fix it ? After all,
    open source suffers from tragedy of the commons - i.e. given the choice of
    putting effort into something that will pay the family bills (and give me a
    sense of achievement) and something that will only give me a sense of
    achievement, I'm not irrational enough to turn myself into a pauper or
    parasite of the state by wasting my valuable time fixing open source.

    It only makes rational sense to put time into open source if I were to
    benefit in some secondary manner as a large company or government
    organisation can e.g. by getting training or support contracts, or getting a
    piece of hardware operational. None of those apply to me. I like programming
    and am good enough to make money at it, so it makes much more sense to
    produce "closed source" software and earn money directly from it than try to
    benefit from secondary, indirect and unreliable sources of income (support,
    training etc) that open source provides.
    Easy - there's much non-"open source" code around that's viewable. For
    example take any copy of Visual Studio and look at the source code in the
    libraries. It's not "open source" but it is readable source code. Don't
    forget that the official definition of "open source" as used in relation to
    Linux is very specific - it applies to the licensing terms, not whether or
    not the source code is viewable.

    I've been involved in many projects that have given me access to other's
    "closed" source code. Some has been brilliant, some has been rotten - you
    can't assume as you did that closed source code is bad and that all open
    source code is good.

    Cadae, Jan 29, 2007
  9. Lawrence D'Oliveiro

    Cadae Guest

    I don't understand your question.

    Cadae, Jan 29, 2007
  10. That code was replaced with much improved code. Someone _did_ "dive in and
    fix it", because it was open-source code, and anybody could do that, so
    someone did. Which proves my point that it's much harder for crufty code to
    persist in open-source projects than in closed-source ones.

    For your next example, would you like to choose one that actually backs up
    your point, rather than one which reinforces mine?
    Lawrence D'Oliveiro, Jan 30, 2007
  11. Lawrence D'Oliveiro

    Cadae Guest

    The phrase"dive in and fix it" implies a speedy timeframe for a fix.
    I supplied an example where this was not the case (at least 5 years for a
    fix) and what's more this was for a critical Linux component, one that
    needed urgent attention.

    Cadae, Jan 30, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.