Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Open Source

Free Can Make You Bleed: the Underresourced Open Source 175

jones_supa (887896) writes "After the Heartbleed fiasco, John Walsh brings attention to the lack of proper manpower and funding to run various open source projects. Free is not usually a bad thing, but it can be when it causes the software your business depends on to be under resourced. 'OpenSSL for example is largely staffed by one fulltime developer and a number of part-time volunteer developers. The total labor pool for OpenSSL maybe adds up to two fulltime developers. Think about it, OpenSSL only has two people to write, maintain, test, and review 500,000 lines of business critical code. Half of these developers have other things to do.' Theo de Raadt has also spoken about too much donations coming from the little people instead of companies, and not too long ago even the OpenBSD project almost couldn't pay its power bills. Walsh goes on to ponder security of open source software, the 'many eyes' phenomenon, dedicating people to review code, and quality control."
This discussion has been archived. No new comments can be posted.

Free Can Make You Bleed: the Underresourced Open Source

Comments Filter:
  • Lol whut? (Score:5, Insightful)

    by Anonymous Coward on Saturday May 03, 2014 @08:35AM (#46907191)

    If your business relies "critically" in its functions on such a piece of software, how would you as a business owner ensure the continuity of the "critical" function?

    A. Hire someone to maintain and work on that software.
    B. Whine about someone not giving you their time for free.
    C. Buy a commercial solution which costs you 50 k USD a year and has at most same level of support as OpenSSL (though better packaged and you get to chat with the smooth sales rep)

    What do you do?

    • A. Hire someone to maintain and work on that software.
      B. Whine about someone not giving you their time for free.
      C. Buy a commercial solution which costs you 50 k USD a year and has at most same level of support as OpenSSL

      $50K a year can be a bargain compared to development and maintenance in-house. A $50K donation to a project like OpenSSL will underwrite maybe six months work by a full-time developer.

      • $50K a year can be a bargain compared to development and maintenance in-house.

        Don't forget that what is "outsourced" for you is "in-house" for the outsourcer. If you can't beat him on price and assuming similar labor costs, it means you have poor/too much management overhead.

        • Not necessarily - it could also mean that your business doesn't do software development. A business already focused specifically on developing the software in question is going to be able to translate that $50k into much greater improvements than the car rental agency that is simply relying on that software as part of their infrastructure.

          • by Teancum ( 67324 )

            The same could be said about a non-profit group that receives a $50k donation towards its activities. If anything, a non-profit group might even be able to leverage that $50k to go a whole lot further than a for-profit software development company simply because there are volunteers who can perhaps be managed better by a paid manager-architect or that such a donation could secure for a long time the hosting services and other aspects of that open source (presumably) project.

            The problem with a non-profit gr

            • by mpe ( 36238 )
              The problem with a non-profit group developing software in this fashion is the tragedy of the commons situation, where many people (and companies) who would be paying the $50k without blinking an eye towards the commercial solution all of a sudden go nuts and have their board of directors breathing down their throat because they made the donation for nearly the same amount.

              Or even would have no issues with multiple $50k per annum proprietary "support" contracts, but $5k one off for OSS is somehow a proble
        • $50K a year can be a bargain compared to development and maintenance in-house.

          Don't forget that what is "outsourced" for you is "in-house" for the outsourcer. If you can't beat him on price and assuming similar labor costs, it means you have poor/too much management overhead.

          Or, the commercial $50K a year solution has the advantage of scale by spreading its cost on multiple customers. If the commercial provider has 1000 customers paying $50K a year, the economy of that is hard to beat by being lean on management overhead.

          • The problem with the $50K commercial solution is that they want you to pay $50K next year too. If their software does what you want already, then that's a hard sell, so typically they persuade you by adding new features. For something like OpenSSL, new features mean new ways of introducing vulnerabilities, so are often the last thing you want.
          • by jedidiah ( 1196 )

            > Or, the commercial $50K a year solution has the advantage of scale by spreading its cost on multiple customers.

            Or not. Throwing money at a corporation is no gaurantee that you will get something that's any better than what you can get for free. All you are doing is buying a yourself a delusion. Perhaps your upper management buys into the same insanity. That doesn't make it any less insane.

            All that a commercial solution ensures is that you can never really now what kind of crap you're dealing with, you

      • You don't need to have the developer work on it full time. He can do other things, too.
    • Re:Lol whut? (Score:4, Insightful)

      by JaredOfEuropa ( 526365 ) on Saturday May 03, 2014 @10:55AM (#46907899) Journal
      A. In a lot of cases this is a managable risk. You don't even need a full time employee; if an issue occurs (and if you manage it right, you'll often know about it ahead of time) you just hire a troubleshooter contractor for a few weeks to fix things. We've done this a few times with both FOSS software, and Mickey Mouse in-house software (think Access / VBA stuff), and in all cases the fix was faster and cheaper to apply than with comparable proprietary software.

      And I'll let you in on a little secret: some teams writing proprietary software are also understaffed. The difference is that you won't know that they cut corners until things go bad. On the plus side: you get to blame the vendor instead of being blamed for your reckless choice of FOSS.
      • So, instead of having a full time employee to fix the issue when it occurs, you're proposing a full time manager to watch when the issue occurs, and temporarily hire an employee to fix it at that time?
        • No. There will be an employee responsible for monitoring the application, though of course that is not a full time job just for one application. The responsibility can be given to an application specialist (handling many apps in a certain domain), a portfolio manager, or the manager of a support team for that domain. When the issue occurs, support usually notices it first and kicks it up to the responsible manager. That manager then brings in a contractor developer with strong troubleshooting skills, an
      • by mpe ( 36238 )
        And I'll let you in on a little secret: some teams writing proprietary software are also understaffed.

        There's also a possibility that the team will be disbanded before (or soon after) the product "ships". Thus some completly different team (or none at all) has the "snag list". (Possibly filtered through several layers of "it's a feature not a bug" levels of "support".)
    • by mpe ( 36238 )
      A. Hire someone to maintain and work on that software.
      B. Whine about someone not giving you their time for free.
      C. Buy a commercial solution which costs you 50 k USD a year and has at most same level of support as OpenSSL (though better packaged and you get to chat with the smooth sales rep)


      There's also option D: Support which looks good on paper and ticks all the right "boxes". But turns out to be worst than useles in practice. (Typically with the person who has to use the "support" having had little t
    • by DogDude ( 805747 )
      That's a no-brainer. You buy the software. I spend a small fortune on traditional non-open source software, and its worth it.
  • by eexaa ( 1252378 ) on Saturday May 03, 2014 @08:42AM (#46907215) Homepage

    From a bit different perspective (largely unix-practical) -- when not having enough resources, you are forced to keep stuff simple. That's usually good, isn't it?

    Anyway, I always wondered why is OpenSSL such a bloated pile of code. It does one god damn gazillion things tightly packed. Now, TLS implementation itself is pretty simple, Key management tools are pretty simple, PKCS verification tools are pretty simple, mathematics behind that is pretty simple, commandline tools for quickusing the maths are simple, relationship between those entities ("APIs") are well-defined and usually clear. Who stuffed all of it into one project?!

    PS. Bonus paranoia&FUD I saw today: http://pastebin.com/gjkivAf3 [pastebin.com]

  • by Jody Bruchon ( 3404363 ) on Saturday May 03, 2014 @08:44AM (#46907225)
    The author works for the actual SSH company that sells commercial SSH software. Though the points may largely be valid, a lot of the slant in the article is meant to tell people "this is what happens when you don't pay for software, so buy our commercial stuff today. Because it can't POSSIBLY suffer from the same kind of mistake, right? Right guys? ...guys?"

    SSH programmers make mistakes. The article writer has an agenda and it's quite obvious. There is no reason to assume SSH is of any better quality than OpenSSH. He even shoots his implication in the foot: "are you going to review two year old patches for errors? No, of course not." This is no different in paid software. If it gets missed during any sort of review, the hole remains. See the recent IE 0-day hole (which has only been around for over a decade) for proof that this is true.
    • While you have a point, you could also take away from the article that OpenSSL needs money.

      • Oh, OpenSSL desperately needs money, as well as programmers. The problem is that OpenSSL is not "fun" to work on and is something that largely sits in the background. Everyone knows what Firefox is because it's a big fancy graphical program that does nice things, but OpenSSL and GnuTLS and NSS are kind of obscure because they're just packages that add something to other programs. Libraries often suffer from lack of programmers and funding. It would probably help if there weren't so damned many SSL/TLS stack
        • Oh, OpenSSL desperately needs money, as well as programmers

          If they need money and programmers, why are they wasting time and effort implementing OpenSSL extensions people don't actually need? Why are they wasting their time writing their own memory manager? Why are they writing in plain C?

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            why are they wasting time and effort implementing OpenSSL extensions people don't actually need?

            You say that like there was some kind of central management decision to implement heartbeat instead of something else. There wasn't. There was just some guy who sacrificed his personal time to implement a feature that may be useful to some (maybe not to you). What have you done for OpenSSL so far?

          • by mikael ( 484 )

            I would guess writing their own memory manager was for "speed", and "security". No one could then hack the encryptors/decryptors by replacing malloc/free functions with their own functions in order to gain access to the data.

            • A project with limited resources doesn't have a prayer beating existing, highly optimized memory managers. And by writing their own, they actually ended up being less secure, because many standard memory managers would have prevented Heartbleed.

          • by mpe ( 36238 )
            If they need money and programmers, why are they wasting time and effort implementing OpenSSL extensions people don't actually need?

            "Feature creep" is common in software.

            Why are they wasting their time writing their own memory manager?

            Possibly one of the platforms has (or had) a buggy memory manager. A better approach to these situations is use a separate library with malloc (or whatever replacements). Which enables the standard functions to be used where the original issue isn't present.
      • Re: (Score:3, Interesting)

        Comment removed based on user account deletion
    • There's also the matter that OpenSSL and OpenSSH are different animals. OpenSSH is audited, much as OpenBSD is itself.

    • by MightyYar ( 622222 ) on Saturday May 03, 2014 @09:13AM (#46907345)

      Despite the slant, I actually came away impressed at the demonstration of efficiency: 2 developers are doing the work of perhaps thousands if the tools weren't open source.

      • That's something I came away with as well. Other than this programming error, "two full time developers" have maintained OpenSSL for years. Makes me wonder how many programmers SSH.com employs and how they perform relative to the OpenSSH "team."
        • by mpe ( 36238 )
          Makes me wonder how many programmers SSH.com employs and how they perform relative to the OpenSSH "team."

          Assuming this is a useful metric in the first place. The Mythical Man Month and Other Essays on Software Engineering by Frederick P. Brooks Jr. is still in print, after nearly 40 years. Wonder if it's relevent here :)
      • by NapalmV ( 1934294 ) on Saturday May 03, 2014 @10:17AM (#46907695)
        Let's reformulate: 2 developers are doing the work of perhaps thousands of managers, HR, legal, PM, accounting etc. employing 2 developers.
      • by mpe ( 36238 )
        Despite the slant, I actually came away impressed at the demonstration of efficiency: 2 developers are doing the work of perhaps thousands if the tools weren't open source.

        With OSS it's fairly easy to find out things like the number of developers. With proprietary software finding this out is likely to be considerably more difficult.
        It's very unlikely that much software which has thousands of developers. Possibly thousands of "gatekeepers", "hangers on", etc.
        • I meant that there would likely be several hundred independent closed-source implementations. I wasn't implying that SSH would require thousands of developers to implement a single time :)

  • Cheap ass gits. (Score:5, Insightful)

    by serviscope_minor ( 664417 ) on Saturday May 03, 2014 @08:45AM (#46907227) Journal

    If your business is depending *critically* on a piece of free software then don't be such a cheapass git. Hire a developer or allocate some of your budget to fund the project.

    Problem solved.

    • As a programmer who uses git daily, your use of the word "git" in this sentence has proven amusing. They should add a "git donate" command...
      • Re:Cheap ass gits. (Score:4, Informative)

        by TapeCutter ( 624760 ) on Saturday May 03, 2014 @11:03AM (#46907925) Journal
        A moron in the UK is commonly referred to as a "useless git". A "git" is an old ironworkers term, it's the (useless) bit of metal that solidifies in the pour hole of a cast. I think "git" software derives it's name from the way some Americans pronounce "get", but I have no idea if that's true..
      • You've got to wonder what Torvalds was thinking when he used an insult as the name for his project. Right up there with GIMP for marketability.

        • You've got to wonder what Torvalds was thinking when he used an insult as the name for his project.

          No you don't. Form Torvalds:

          "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

          He knew exactly what git means in English (an unpleasant person).

    • by AHuxley ( 892839 )
      Must have been an interesting meeting: just drop in the free code like the rest of our wealthy, skilled competitors do.
  • BS (Score:5, Insightful)

    by NapalmV ( 1934294 ) on Saturday May 03, 2014 @08:55AM (#46907271)
    How many programmers does Microsoft have? Are their products bug free as a result?
    • How many programmers does Microsoft have?

      Lots.

      Are their products bug free as a result?

      No, they charge for the bugs; As I recall, those are the features.

    • The best part is that not even two weeks after heartbleed was disclosed, Fire eye announced [fireeye.com] a vulnerability in IE that affects everything from 6 to the latest release 11. In response to the wide range of the vulnerability several agencies declared IE persona non grata till it is fixed. So much for commercial software being more secure.

      • by mpe ( 36238 )
        The best part is that not even two weeks after heartbleed was disclosed, Fire eye announced a vulnerability in IE that affects everything from 6 to the latest release 11. In response to the wide range of the vulnerability several agencies declared IE persona non grata till it is fixed. So much for commercial software being more secure.

        IE would be better described as Gratis and Proprietary. AFAIK it's never been sold...
  • by walterbyrd ( 182728 ) on Saturday May 03, 2014 @08:56AM (#46907283)

    This article is nothing but pure propaganda.

    Free software may not be perfect, but, from a security standpoint, it easily beats microsoft, and most other proprietary software.

  • Money no guarantee (Score:4, Informative)

    by LordLucless ( 582312 ) on Saturday May 03, 2014 @09:15AM (#46907359)

    Free is not usually a bad thing, but it can be when it causes the software your business depends on to be under resourced.

    Of course, paying money for closed source software is no guarantee that it's going to be adequately resourced either. Compare the two most recent, high-profile flaws, both very similar, in that they deal with memory allocation issues:
    - Heartbleed on SSL has a team of 2, was extant for 2 years, was patched in 6 days, and the patch was available to anyone who used the software
    - CVE-2014-1776 on Internet Explorer. Don't know how many people the team, was extant for 13 years, was patched in 6 days, and the patch was originally going to be denied to users who hadn't upgraded recently.

    This does not seem to be an issue with closed vs open source development models - both have had major vulnerabilities extand for far too long, and both can turn around fairly rapid patches when needed. Doling out cash to Microsoft is no more effective at securing your applications than using free open source products.

  • by bug1 ( 96678 ) on Saturday May 03, 2014 @09:18AM (#46907363)

    The only way corporations are going to carry their fari share of the burden is if they are legally required to. The only way to do that is to make them pay with $, its all they understand.

    Libre software is being used by corporations to build gold-plated cages for consumers. Its time to stop playiong their game.

    Our glorious leaders are fundamentally wrong on the concept that software tshould be "free to use for any purpose", it should be free to use for the purpose of ensalving us.

    • by bug1 ( 96678 )

      it should not be free to use for the purpose of ensalving us.

      Duoh

    • Too many problems.

      Look at the serious issues that surround CC BY-SA-NC -- you have two sets of "copyleft" material that are completely incompatible, and you have one set that has an extremely ill-defined definition of "commercial". Is advertisement supported commercial? Is use in a business setting for an internal system commercial? Is it just commercial if you're selling something that includes a copy of the work?

  • by Opportunist ( 166417 ) on Saturday May 03, 2014 @09:23AM (#46907399)

    The problem is not that the software is free (as in open). The problem is that people (and companies even more) perceive it as free (as in beer). That that's the main misconception.

    Companies want to cut corners by using OSS. They don't do it because it's easier to review, easier to adapt or easier to find someone who can audit it sensibly. They want it because they can grab it and use it without having to pay anyone for it.

    And that simply won't fly. Because that entails the "can't someone else do it?" attitude. Yeah, the code should be reviewed. But someone else will do that, we needn't spend money on that. And it should be audited, but can't someone else do it and we save some money?

    Funny enough, the fact that anyone can review, audit and fix things is also the reason why nobody does it. It's a bit like that job in your company that anyone could do, and since anyone can do it, everyone relies that someone else will. There's so many who can, at least ONE of them will. Right? RIGHT?

    And since the fact that it is "cost neutral" (to avoid saying the ambigious free) is one of the criteria, if not actually THE criterion, why an OSS product is chosen 999 out of 1000 times in a corporation environment, you may rest assured that the same cheapskates that chose OSS because they can pinch a penny will not spend it on auditing it.

    • You are ignoring the fact that paid software is no better.

      • Paid software is not better. Oddly, though, companies are more willing to invest in "accessories" for paid software than for free software. It seems to be a human thing, or maybe it's a manager thing, I don't really get either, humans or manager. But as soon as money is involved, expectations seem to rise and when managers threw some money at it already, they seem to be more willing to throw some more money at it, too. To audit, to review, to ... whatever.

        I don't really know why it is so much harder to get

    • by sirwired ( 27582 ) on Saturday May 03, 2014 @10:01AM (#46907607)

      One follows from the other. If your Free license says that anybody that works on your product is required to give away their efforts for free-beer free, it should not be surprising that it's difficult to find companies to spend money on something (like paying a developer) that won't give them a competitive advantage. This, incidentally, is why we have taxes; it forces people (and companies) to pay for the common good. We wouldn't have much in the way of public works if they relied solely on charitable donations and user fees.

      This is a persistent weakness of Free software, but you'll never get RMS to admit that money to pay for programmers does not magically fall from the sky. People are cheap, and if they can get something for free, it's no shock that few of them will pay for it.

      In my mind, an ideal software license would have the following;

      1) Mandatory Code Release (This gives you some software Freedom)
      2) Payment required to copy and/or use the software.
      3) Some sort of revenue sharing scheme so that any contributors to the code receive a portion of the funds collected.

      Think of it like a "software co-op license"

      (This, incidentally, is how industry standards commonly work in the hardware business. You want to implement the IEEE 1234.567 standard? You pay up a standard fee per implementation, and that's doled out to the contributing companies.)

      • by trparky ( 846769 )
        Personally, I think the concept of FOSS should be torn down and rebuilt; at least the free part of it.

        For instance...
        Free: If you use this library in another free product. For instance, if you make a small program which you give away for free, then you are allowed to use said library for free.
        Not Free: If you use this library in combination with systems that essentially make you a ton of money, you are legally required to pay a license for the use of the library in question..
        .
        FOSS may be a wonderful t
      • by Kjella ( 173770 )

        3) Some sort of revenue sharing scheme so that any contributors to the code receive a portion of the funds collected.

        This is where your logic has a flaw so big you could drive a semitrailer through it, standards are set but open source evolves. Let's say version 1 is created and you charge $10/copy. Now a person makes a patch and wants $2 for his work, does he now charge $12? Then this becomes a pyramid scheme of accumulating prices where you want to get it in early, no matter what anyone does with the project later you get $10 practically forever. That guy who contributed a small patch to Linux in 1992 would still collec

      • but you'll never get RMS to admit that money to pay for programmers does not magically fall from the sky.

        Ever read anything he's written? He is all in favor of people charging for Free software, one way or another. He believes that programmers can live very well doing software internal to enterprises, and in his talks usually points out that most developers do. (It would make no difference if our internal, strategically vital, software were under the GPLv3, because we're never going to distribute it.)

  • Timing is pretty convenient. We have a tale of two exploits:
    -Heartbleed. Open source project. Huge catastrophic bug, existed as of beginning of 2012. Fix available pretty much immediately upon discovery. As a result, significant resources are pouring in to proactively examine OpenSSL, some fixing and some forking OpenSSL. One way or another, the fix was immediate and concerned parties are empowered to do what they think is needed and the open source world will have risks mitigated as well as closed sou

  • Who woulda' thunk it? You Get What You (Collectively) Pay For. It doesn't matter if "payment" is in the form of money or manpower. If software you use is built by labor effort much smaller (in cost and/or size) than is usually needed for a project of a particular size or complexity, it should come as no shock that the product ends up not being the quality it needs to be.

  • Oh dear, yet another Harvard BizSch / Big Business canard that FOSS is governed by the contraints of closed software. Resources only matter when they are restricted -- ie only [certain] employees can fix the code.

    FOSS does not have this restriction _AT_ALL_ and that is one of it's greatest strengths. Torvald's "With enough eyeballs, all bugs are shallow." Yes, limited resources may mean it takes a while for an offical patch (still quicker than MS) but unofficial patches can and are generated by anyone in

    • When you have a widely-used, yet complex, product that nobody has to pay for, doesn't require tech support (unlike, say, an OS), doesn't have any provisions for proprietary (i.e. non-free) features, and isn't really much fun to work on (unlike, say, a compiler), it should come as no shock that it's somewhat difficult to recruit enough eyeballs to look for all those bugs.

      Yep, a patch can be issued quickly, but a project with sufficient access to resource ahead of time breaks less to begin with.

  • They overlap and interact in unexpected ways, along with the theft economy and the subsistence economy. OpenSSL is a prime example of these overlaps and the complexities of trying to manage all that socially. Should the planned government economy make the code work via tax-supported staff of a government agency? Should businesses exchange money for more development work and support services specific to their needs? Should more developers just donate their time or individuals donate their funds to make OpenS

  • So how many developers does OpenSSL need for maintaining the code base?

  • Heartbleed was the result of someone adding an optional and useless feature to OpenSSL that should never have been added in the first place. That's not a problem with having insufficient resources, it's a problem with poor management.

    If it has anything to do with resources, it's a sign that people on the project have too much free time on their hands, because if there had been anything important to be done, people wouldn't have the time to add this feature.

  • by plopez ( 54068 ) on Saturday May 03, 2014 @10:28AM (#46907769) Journal

    Understaffed to save money with a huge backlog, insane deadlines, cut corners, and massive scope creep. So what's his point?

  • Inadequate resources is hardly the exclusive domain of Open Source projects. Nor is a failure to adequately vet code particularly reflective of an open development model. The insecure, buggy code in the devices used in the world's infrastructue display those facts, perfectly. Device manufacturers tend to focus on hardware, underfund and understaff their software development and demand unrealistic delivery times. These are, by and large, proprietary endeavors.
  • ...where the CEO's idea of the time it takes to develop anything is off by a factor of five, and every developer is also an IT guy and half a dozen other things, how exactly?
  • by jopet ( 538074 ) on Saturday May 03, 2014 @03:38PM (#46909399) Journal

    The ones now complaining about how risky it is to rely on open-source software are exactly thos thousands of companies who just use open-source and never give anything back, usually not even provide a patch ever. It is not the fault of open-source it is the fault of greedy assholes who just take, never give back and then complain and bash.

  • Companies routinely underfund development staff, overwork them, and then end of life products in order to shove 2.0 out. I don't know why everyone's making a big deal out of 'heartbleed'. There have been exploitable faults in open and closed software many times before, some of which have been worse.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...