Closed-source software follies

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

  1. Here's an entertaining story
    <http://www.infoworld.com/article/07/01/23/05OPrecord_1.html> 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
    1. Advertising

  2. Lawrence D'Oliveiro

    Cadae Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:ep9j70$egg$...
    > Here's an entertaining story
    > <http://www.infoworld.com/article/07/01/23/05OPrecord_1.html> 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).


    Great story. The company clearly wasn't listening to its technical advisors,
    and paid the price.

    > 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.


    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:
    http://www.linuxhq.com/kernel/v1.0/3/lib/malloc.c 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.

    PC
    Cadae, Jan 25, 2007
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    thingy Guest

    Lawrence D'Oliveiro wrote:
    > Here's an entertaining story
    > <http://www.infoworld.com/article/07/01/23/05OPrecord_1.html> 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.


    Not unknown, in fact depressingly frequent...one 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 quality....so the end
    user is not ass raped by greedy slaes ppl.

    regards

    Thing
    thingy, Jan 25, 2007
    #3
  4. In message <45b8717d$>, Cadae wrote:

    > For example look at this - one of the most important Linux library
    > routines- malloc:
    > http://www.linuxhq.com/kernel/v1.0/3/lib/malloc.c 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.


    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 <http://lxr.linux.no/source/mm/slab.c>, in a
    lot cleaner and more maintainable fashion than the obsolete example you
    posted.
    Lawrence D'Oliveiro, Jan 26, 2007
    #4
  5. Lawrence D'Oliveiro

    Cadae Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:epbrqv$h0a$...
    >
    > 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?


    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
    96.
    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"
    code.

    > The current Linux kernel memory allocator is actually called kmalloc, and
    > you'll find it defined here <http://lxr.linux.no/source/mm/slab.c>, in a
    > lot cleaner and more maintainable fashion than the obsolete example you
    > posted.


    Only after many years had passed did this essential bit of code get its
    long-overdue improvements.



    PC
    Cadae, Jan 26, 2007
    #5
  6. On Fri, 26 Jan 2007 21:26:17 +1300, Cadae wrote:

    > 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
    > 96.
    > 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.


    Surely it has already been fixed, has it not?


    > 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.


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


    > The same is true for "closed-source" code.


    How would you *know that* if you cannot see the source code?


    --
    Dianthus Mimulus

    Microsoft's business practises exposed in court:
    http://www.maxframe.com/DR/Info/fullstory/dsprgmnt.html#_Toc447960918
    Dianthus Mimulus, Jan 26, 2007
    #6
  7. In message <45b9bb2e$>, Cadae wrote:

    > "Lawrence D'Oliveiro" <_zealand> wrote in message
    > news:epbrqv$h0a$...
    >>
    >> 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?

    >
    > 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 96.
    > 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.


    So where is that code now?
    Lawrence D'Oliveiro, Jan 26, 2007
    #7
  8. Lawrence D'Oliveiro

    Cadae Guest

    "Dianthus Mimulus" <> wrote in message
    news:...
    > Surely it has already been fixed, has it not?


    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.

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


    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.

    >
    > How would you *know that* if you cannot see the source code?


    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.


    PC
    Cadae, Jan 29, 2007
    #8
  9. Lawrence D'Oliveiro

    Cadae Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:epe203$ekn$...
    >
    > So where is that code now?


    I don't understand your question.

    PC
    Cadae, Jan 29, 2007
    #9
  10. In message <45bdc1a5$>, Cadae wrote:

    > "Lawrence D'Oliveiro" <_zealand> wrote in message
    > news:epe203$ekn$...
    >>
    >>In message <45b9bb2e$>, Cadae wrote:

    >
    >>> "Lawrence D'Oliveiro" <_zealand> wrote in
    >>> message news:epbrqv$h0a$...
    >>>>
    >>>> 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?
    >>>

    >> 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 96. 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.

    >
    >> So where is that code now?

    >
    > I don't understand your question.


    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
    #10
  11. Lawrence D'Oliveiro

    Cadae Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:epm6ms$3hg$...
    > In message <45bdc1a5$>, Cadae wrote:
    > 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?


    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.

    PC
    Cadae, Jan 30, 2007
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vlvetmorning98

    "titicut follies"

    Vlvetmorning98, Feb 22, 2004, in forum: DVD Video
    Replies:
    6
    Views:
    1,815
    Anonymous Joe
    Feb 29, 2004
  2. steve
    Replies:
    9
    Views:
    320
    steve
    Mar 3, 2004
  3. Lawrence D'Oliveiro

    Open-Source Good, Closed-Source Bad

    Lawrence D'Oliveiro, Oct 16, 2005, in forum: NZ Computing
    Replies:
    1
    Views:
    447
    Gordon
    Oct 16, 2005
  4. Lawrence D'Oliveiro

    Closed-Source vs Open-Source Drivers

    Lawrence D'Oliveiro, May 4, 2009, in forum: NZ Computing
    Replies:
    2
    Views:
    493
    Lawrence D'Oliveiro
    May 5, 2009
  5. Lawrence D'Oliveiro

    Open Source vs Closed Source Security

    Lawrence D'Oliveiro, Mar 3, 2010, in forum: NZ Computing
    Replies:
    1
    Views:
    946
    Gordon
    Mar 4, 2010
Loading...

Share This Page