Does open source usage free your budget up for the best talent?

Does open source usage free your budget up for the best talent?

Summary: Here's a great "opportunity cost" question.  It's no secret these days (just look at the gazillions of studies) that it's not necessarily cheaper to run a business with open source software than it is to run "closed-source" commercial software.

TOPICS: Open Source

Here's a great "opportunity cost" question.  It's no secret these days (just look at the gazillions of studies) that it's not necessarily cheaper to run a business with open source software than it is to run "closed-source" commercial software.  The actual costs just show up in different places.  But what rarely gets explored are the trade-offs that are made when your fixed budget is spent in different places. 

For example, what would you rather have?  A support contract for your IT with a Fortune 500 company? Or, in lieu of that, the very best in-house talent to run your open source-based IT? Most companies can't afford the luxuries of both.  That question never crossed my mind until Dabble CEO Mary Hodder answered the very last question in my interview of her which is available as a podcast here on ZDNet. I've been stewing on her answer for a couple of days now because of how well and succinctly she captured the essence of that trade-off.  The start-up technology for Dabble (which launched this week) is all open source: FreeBSD (the operating system), Apache (for Web servicing), and MySQL (for the database).  When I asked her if the choice to go with open source is helping her to keep costs in check, here's what Mary said:

What happens with open source is you actually spend the same amount of money, but you don't have lock-in and you pay for really good people to run it.  And so you still end up paying. But you just pay in a different place. And I think it's a much more sustainable model for that kind of server/software development.

On multiple occasions during the interview, Mary spoke very highly of Dabble's engineering team, making it very clear that they were the key to Dabble's success.  Personally, speaking, having managed people for more than 20 years, I would generally do anything to open the budget up if it meant getting better people.  And never is having the right people more important than when you're starting something up. Moving forward, as more businesses startup (and now is a good time according to Dan Farber's coverage of the AlwaysOn conference) and need to make this choice, the more this will be a thorn in the side of commercial software companies that need new customers to sustain revenue growth (as opposed to holding steady with support contracts from their existing customers who are loathe to upgrade).

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • ASSUMPTIONS is the mother of all F*CKUPS

    OSS with NOT skilled developers would still be a failure.

    OSS with support would still cost the same as closed source.

    You are making a big assumption that OSS developers are more skilled.

    Also the cost of software is negligeable compared to the cost of paying salaries.
  • A common fallacy

    I've seen this argument made many times before. The issue is that OSS [b]Requires[/b] more expensive talent to keep it operational because by and large it is not as complete or as capable as its commercial equivalent.

    What's more, it can be even more costly if you are a company which must frequently change to stay competitive because of this inheirent lack of capability and features.

    I'm not saying that OSS doesn't fill a niche in some place within an enterprise, but when it comes down to what you run your business on, better for the company to rely on feature rich and often times more flexible commercial software that eliminates the need for your own staff to do all the plumbing and to bring it up to the same par as the commercial packages, and focus on just those things which provide that business competitive advantage over their competitors.
    • Interesting theory.

      However, the assumption (that OSS REQUIRES more expensive talent) isn't factual within the domain. The domain is companies like Dabble that need to create customized solutions. We're not talking about maintenance functions for which you want to hire a mouse-clicking monkey. We're talking about real developers.

      We're also talking about something that's specific to that company. The vast majority of corporate programmers work on software that's company-specific, and MOST of the time, that software is less polished than commercial packages. That's normal and expected, because you're not having to meet the operational needs of the masses; instead you're providing the functionality that YOU ALONE need (and only that functionality). To provide any more than that is a waste of your corporate funds. If the plumbing is already meets your needs (note that it does NOT have to be on par with commercial packages, which are intended to meet other people's needs), then you can focus on your competitive advantages immediately. When you're looking at something like Dabble, which is doing something new, you want to have the best talent available for that purpose. If eliminating expensive licenses (software and maintenance) gets you those programmers, then you start with a competitive advantage.

      As for price, I've worked with both OSS and proprietary software, nearly all of it custom development. Those high-talent developers I know that do OSS would rather work on OSS than proprietary systems. They're not looking for a higher paycheck for one vs. the other (indeed, some would take a pay cut just to work on a project they like). Here, Mary Hodder isn't paying a premium for OSS developers; she's paying for QUALITY developers. When the licenses raise a barrier to obtaining quality where needed, she's right to build on Open Source.
  • Service/subscription can be tied to business value

    I think another benefit of where the cost is incurred with open source (and this is also true of SaaS) is that it can be more closely aligned with value generation. With the traditional, perpetual license model this is much more difficult, since the license cost must be equated with estimated/anticipated value. With a subscription-based model - either an open source support/maintenance subscription or a SaaS application subscription - the cost can be flexed in line with the value generated. This has the additional benefit of keeping the provider more honest since, unlike with the perpetual license model, the provider must maintain the service since if they want to continue to receive the revenue
    • ownership of applications and copyrights

      If you work for a regular corporation, all software developed becomes property of Microsoft, even the documents, because the corporation has a license to use Microsoft's applications and tools.
      A corporation that uses open source tools and systems, it actually owns all applications and files developed in house, and the employees hold the copyrights. Time and effort is much better rewarded, and you are not enslaved by Microsoft. If you assign a value to freedom, then you win.
  • Make vs. Buy

    Shrink-wrap vs. F/OSS is the classic make/buy decision, with high threshold on the "make" side. For a company which [b]must[/b] make their own anyway and thus pay the threshold of having developers, the incremental payoff isn't the same as the average payoff/cost.

    In that case, the greater flexibility of F/OSS comes into play. Paying a bit more for really good developers produces huge payoffs. The fact that you can skip the license costs is really just gravy.
    Yagotta B. Kidding
  • A different perspective ...

    David, your talkback audience seems to be missing the point -- but so is Mary! Mary's example applications (implemented at Dabble) are FreeBSD, Apache, and MySQL -- and they require no more (or less) talented people than similar solutions from proprietary vendors.

    If these were not OSS products, then most likely their environment would have been built upon some flavor of proprietary UNIX -- because UNIX and FreeBSD have the same roots. Had the underlying OSS been Linux, the picture still would have been the same because Linux was derived directly from the need for UNIX functionality. The talent needed to take care of any of these three environments would have required exactly the same skills, and thus the 'costs' associated with hiring the talent would have been exactly the same.

    There is no doubt in my mind that the people you hire have more to do with success than the selected platform.

    Yes, if Dabble had selected a support contract instead of hiring in-house staff to take care of IT, that support contract might have come at a higher price but it would also have gone on the books as a different kind of expense with different (perhaps more favorable) tax implications.

    Further, there is no way to know if the quality of people available to the support provider is equal to, or greater than, the calibre of people you can hire on your own.

    The relative costs also depend upon if you can keep in-house hires busy enough to justify a 40-hour week. If you cannot, the support contract might actually cost you less.

    Further, Dabble could have made the same OSS software choices and hired a third-party for support just as easily as they could have made a proprietary choice and hired in-house staff.

    Deciding what support model to use is completely independent of deciding whether to use OSS or proprietary software.

    Mary also assumes that once you go with a proprietary vendor that you are somehow locked-in. In a business setting, IT purchases are based upon a three-to-five year return on investment. None of the OSS tools she described would preclude moving to similar CSS (closed software solutions) in the future and the reverse is also true. Either investment ties you in for three to five years, depending upon your accounting decisions. No more, no less.

    It is true however that if you purchase a support contract today, three years from now, the IT folks you choose to hire have no more familiarity with your system than they do today, and the cost of that learning curve down the road may be higher than the costs if they are involved in the project from the start but all that does is make the case for in-house IT staff. It has little to do with whether or not you go OSS or CSS.
    M Wagner
  • Make vs Buy is perhaps at 90 degrees

    Folks seem to be confusing several business decisions here. Make vs Buy for original software, make vs buy for support and then costs of implemention of canned shirkwrap stuff vs FLOSS.

    The application here seems to have required some customization, which in general is easier with FLOSS. Since the authors of FLOSS tend to have variable problems to solve and different world views most FLOSS tends to have places where you can change a file and thus change the behavior. Also if I major change IS required, the option is to patch the source code, a risky option just becuase you will have to track the patch, unless you can get your change accepted by the author, then it beocmes yet another option ....

    With the shirk-wrap stuff you may have to design a wedge to go between stuff to get it to work your way.

    Now the point that folks are trying to make, you can hire someone to implement FLOSS for you, or you can hire staff to do it. You can also make the same choice for the Canned stuff- except the first x dollars goes to the original vendors for licence fees, you can still decide what to do with the rest of the cost.

    Now the advantage she is finding is that if she spends to have internal staff, they eventualy become more skilled in their jobs and so more effective. the second years licence for a canned product does not give you anything different from the previous years, particulaly if as in many shops you are reluctant to change versions for fear of incompatabilities. The floss shop can do incremental upgrades (or not) on their own schedule- not some vendors.
  • Interesting to note that ....

    Most of the people including the author of this blog, I'm pretty sure that they dont program.

    Having compute science education and being a programmer has a world of difference. Having a degree in computer science does not mean one can program.
    • programmers are all knowing...

      I program,
      but I still don't see your point.
      I think developing custom apps within the closed-source framework is the way to go, you get the best of both worlds: tested, supported software and custom applications you develop on the fly within this framework. You get to keep a couple good IT on staff, but they spend their time rapidly creating applications that make the company more efficient, not getting open-source platforms up and running, just to save some support money.
      Get everybody MS Office,
      then hire a programmer/IT admin to go nuts building cool custom Access/Excel applications that make the company run smoother and more efficiently.

      Seems obvious to me...
      • Missed the scope

        This is not about programming or writing macros for Office, it is about designing and writing solutions for a specific business need, where the program is written from the ground up, and optimised to have fast response times using up the minimum of resources.

        In other words real programming where the scope includes architectural design and teams for aspects of the design including user interface, front and back end processing, testing, optimisation, quality assurance, and reappraisal.

        You just can't get this level of indepth design and optimisation by pasting bits onto an Office application.
  • Do you really want your best people working on IT infrastructure?

    Nobody can deny that it's great to attract and retain good people but do you really want to have them maintaining your IT infrastructure or would you rather have them adding business value? I think it's pretty obvious that regardless of whether you source your software from proprietary vendors or open source software service providers, your best peoople should spend their time on things that make your business more competitive, not maintaining the OS or database engine.
  • But developers like OSS

    What I see in my company is that the best developers naturally prefer to use Open-Source software.
    - OSS documentation is often publicly available and it is possible to get fast support from peers
    - Vendors support is contractual but I have experienced very poor quality with several vendors support

    With vendors, you can't do nothing but wait while with Open-Source, you might find the solution yourself, it is more grateful for developers.

    I perceive commercial support, being for a commercial or an open-source product, as reducing operational risks, mostly when the application is already developed and in production.
  • Not Spending on Reinventing

    I think it is a nice way to answer the question, the way the Dabble CEO had...but look at it another the case of a closed software, you might need less support resources, but you might also end up using resources for reinventing what someone else has done elsewhere...which is perhaps not an optimal way, considered in isolation...

    Some thoughts from, where we discuss making money from open source software, @