"In the long run, it is cheaper to build and not buy," said Justin McWilliams, a software engineer in Google's corporate engineering department, which provisions and manages computers and other technology for Google employees. McWilliams shared some of the company's practices at the O'Reilly Open Source Conference (OSCON), being held this week in Portland, Oregon. "We typically don't default to buying a commercial offering. We think about building it from scratch first, or look to the open source world," he said.

Google uses a number of home-built or modified open source programs for IT management, including software for full disk encryption (FDE), remote computer management, compliance management, virtual private networks (VPN), video teleconferencing, and for single sign on (SSO).

Over the past few decades, IT departments at large organizations have learned to purchase commercial, off-the-shelf software to manage their infrastructure, typically because it is less expensive than writing and maintaining the software in-house. Due to a number of factors, however, this approach does not work well at Google, McWilliams explained.

"Even when we buy we still have to build on top of what we bought in order to be effective within Google. We want all of our systems to communicate with one another. Otherwise, we'd just have all these silos of data," McWilliams said. The cost of employing engineers to write and maintain code is still more cost-effective than maintaining costly support contracts with IT management software providers, McWilliams said.

One key reason behind this build-first philosophy is that Google is a rapidly growing company. The company currently has over 32,000 employees, almost twice as many as it did in 2008. Because of this rapid growth, the company's IT staff, which is not growing at the same pace, has to keep scalability in mind when setting up operations. "We have to find other ways to scale. We try to scale by building [in] automation and self-service, as opposed to just throwing more people at the problem," McWilliams said. Typically, use of commercial software can not scale at such a dramatic rates, at least not in an economically feasible way.