Organizations transitioning to open source need to learn both self-sufficiency and how to work with open source communities. And to grow a thick skin against criticism.

Mitch Wagner, Executive Editor, Light Reading

January 3, 2019

7 Min Read
Growing Pains: For Organizations Moving to Open Source, It's a Tough Transition

For organizations used to the old ways of doing business, open source can be a tough transition.

Open source requires self-sufficiency, new relationship skills and vigilance against new kinds of risks, say technologists working at telcos, cloud providers and enterprise IT who've embraced open source.

Open source culture also requires a thick skin against criticism.

"Open source is developed in a radically different methodology than most enterprises are used to when it comes to producing software," says Justin Shepherd, CTO, private cloud, at Rackspace , a managed cloud computing company which pioneered OpenStack open source software for cloud infrastructure, and also supports Kubernetes and other open source projects. (See Rackspace Launches Kubernetes-as-a-Service.)

Freedom of choice is a great benefit for open source -- but it can also be problematic, says Melody Meckfessel, Google (Nasdaq: GOOG) Cloud Platform VP engineering. It requires tough decisions. "You need to do your due diligence to find out which tools to use," she says. (See Google Pushes Enterprise Strategy Beyond the Cloud.)

No Batphone
Developers should start from customer needs to determine which open source projects to adopt, and be sure open source projects are supported by an ecosystem drawn from multiple organizations, says Meckfessel.

Figure 1:

As they deploy and operate open source software, organizations have to learn self-sufficiency. There won't always be a vendor around to rescue them if they get into trouble, says Ben McCormack, who was Evernote Corp. 's chief of staff when we spoke with him in mid-2018. McCormack is now at Google. (See Why Evernote Picked Google Cloud Over Amazon.)

While Evernote was built on open source from the beginning, McCormack started his career at shops that used Oracle Corp. (Nasdaq: ORCL) and Hewlett-Packard technology. "You had to learn vendor and relationship management. All of that goes away with open source," he says.

If you couldn't fix an Oracle problem yourself, "you called your account rep and asked nicely and Oracle made it go away," McCormack says.

That changes with open source. "If you're running a MySQL environment, yes, there are vendors, but generally speaking you're on your own. So the technical people haven't got the Batphone they can call. They have to be more resourceful."

However, this is only a problem for people already established in the workplace. "The next generation of people coming into tech -- guys coming into management roles in ten years -- have no experience of managing a vendor or price negotiations. It doesn't exist anymore," McCormack says.

Be careful about licensing
Organizations using open source code need to be careful about licensing. "Free isn't always free," says Gary Cantrell, SVP & CIO for Jabil Circuit Inc. (NYSE: JBL), a manufacturing company that uses both cloud and open source software. (See Jabil Leverages Cloud to Improve Manufacturing .)

Open source code often carries legal obligations to contribute back to the community, and organizations need to be careful to comply, Cantrell says.

Organizations need to ensure that open source licensing doesn't jeopardize the company business model: for example, by requiring organizations to publish proprietary software because it's linked to an open source project, says Dietmar Fauser, vice president architecture, quality and governance for Amadeus Corp., which provides reservations back-end systems for the travel industry. (See Amadeus Flies With Open Source.)

Organizations that fail to contribute back to the community run the risk of losing out on open source benefits, says Travis Ewert, who was CenturyLink Inc. (NYSE: CTL) vice president, software defined services and big data, when we interviewed him in mid-2018. Ewert now does consulting.(See Here's How CenturyLink Is Cutting Capex.)

Stay with the pack
Developers who fail to work with the larger community can get so far from the mainstream open source project that they're working independently. It becomes more difficult to get support, and to hire talented developers interested in working on a true open source project that's independent of an individual organization, Cantrell says.

Next page: Stand the heat

Stand the heat
Additionally, organizations need to choose open source projects with an eye toward maturity and ongoing support. Be sure the software is in active development, and not abandoned, Amadeus's Fauser says.

A good indicator of maturity and ongoing development is the number of pull requests -- developers submitting changes to the software source code. "Something that has a lot of activity shows that a lot of people are interested and eager to make it work," Fauser says.

Organizations need to be careful that the code's APIs are stable. Future versions of the software need backward compatibility, Fauser says. Amadeus uses the Red Hat Inc. (NYSE: RHT) OpenShift cloud platform in part because Red Hat delivers stable kernels and APIs. Once Red Hat publishes the API, that API is never disrupted. (See Red Hat Simplifies Kubernetes on AWS, Cuts Prices .)

Internally, organizations need to be disciplined to avoid technology sprawl, says Kirby Files, Masergy Communications Inc. software architect. "With places that use all Oracle, or IBM Web frameworks, everyone has been trained on a fairly tight silo of applications," Files says. But at an open source enterprise, like Masergy, different teams use different applications, which can lead to technology fragmentation. "A lot more information sharing has to happen," he says. (See Masergy's Ray Watson: Customers Want Security but Pay for Performance.)

Not everything is suited
And not all technologies are ideally suited to open source, says Ovum Ltd. analyst Tony Baer. Good candidates are commodity technologies with a broad practitioner base that can be converted to contributors. Examples of successful open source technologies include operating systems and developer tools.

Successful open source projects also include data science frameworks and algorithms, programming languages such as R and Python, and development libraries. Other examples of open source success: data platforms such as Hadoop, and analytics and compute engines such as Spark, Baer says.

These are areas with broad practitioner bases where the state-of-the-art changes quickly. "When you have a broad enough base you're tapping into the world's greatest development organization, as opposed to a single vendor," Baer said. "And practitioners would rather work in open source, rather than a proprietary tool, because it makes their skills more portable."

Wall Street is beginning to adopt open source, as firms see it as an option for avoiding reinventing their own basic technologies, such as message brokering. "Message protocols are not their core IP," Baer says.

But you don't see much open source in aviation. They just don't trust it. "This is technology that relies on keeping people alive and transporting them safely," Baer said.

Grow a thick skin
Highly specialized technologies tend to be unsuitable for open source, as do applications such as ERP (enterprise resource planning) and accounting. That's where vendors can add unique IP. Also, developers are just plain uninterested in working on reinventing accounts payable, Baer said. And companies are reluctant to replace their accounts payable system if they don't have to. "That's why you don't see it in the application layer," Baer said. Although there are exceptions, such as SugarCRM.

Lastly, people working at open source projects need to grow a thick skin. A major strength of open source is that development happens publicly. Anyone can critique and make suggestions. Egos can get bruised, says Rackspace's Shepherd.

"The code is visible to everyone, can be critiqued by anyone, and ultimately be improved by anyone," Shepherd says. "There can be a lot of growing pains associated with transitioning to this type of development model. Moving from a system without peer code reviews to a forced peer code review system can be quite a shock for many developers not used to this model."

On the other hand, Shepherd says, "You can now get help from places you never would have expected, like a downstream consumer of your code fixing bugs in your codebase. Quoting Linus [Torvalds's] Law, 'Given enough eyeballs, all bugs are shallow.'"

Related posts:

— Mitch Wagner Follow me on Twitter Visit my LinkedIn profile Follow me on Facebook Executive Editor, Light Reading

About the Author(s)

Mitch Wagner

Executive Editor, Light Reading

San Diego-based Mitch Wagner is many things. As well as being "our guy" on the West Coast (of the US, not Scotland, or anywhere else with indifferent meteorological conditions), he's a husband (to his wife), dissatisfied Democrat, American (so he could be President some day), nonobservant Jew, and science fiction fan. Not necessarily in that order.

He's also one half of a special duo, along with Minnie, who is the co-habitor of the West Coast Bureau and Light Reading's primary chewer of sticks, though she is not the only one on the team who regularly munches on bark.

Wagner, whose previous positions include Editor-in-Chief at Internet Evolution and Executive Editor at InformationWeek, will be responsible for tracking and reporting on developments in Silicon Valley and other US West Coast hotspots of communications technology innovation.

Beats: Software-defined networking (SDN), network functions virtualization (NFV), IP networking, and colored foods (such as 'green rice').

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like