Over the last few years, companies are disrupting established businesses from a software centric model. Some examples are Amazon, Netflix, Uber, and AirBnB. These companies were able to disrupt these industries by leveraging the agility and speed of changes that software can deliver. The largest companies are trying to become software companies. This is why software methodologies are critical for your business strategy today. Companies are realizing that innovation and the agility drive competitive advantage. As your software strategy takes shape, it’s important to consider several aspects of innovation and agility as well as some areas to avoid.

With software strategy now front and center, it’s important to understand open source. Open source technology and strategy are at the core business software transformation and innovation. There are several important reasons for this that makes sense to understand. The first reason is pace of technology innovation and speed of adoption that a community of developers can deliver in open source. It is very difficult for an organization to keep up with the rate of change that a community of developers can. The second reason is around the power of community support and contribution quality. The quality of the code and the rigorous review of the code ensures reliability and production readiness. The last reason I’ll mention is the transparency and openness of the community. The projects road-map is open, Pull Requests can be submitted by anyone, and the acceptance and issues are completely visible. These reasons have led to the emergence of open source being central to your company’s business strategy for digital transformation.

Open source concerns to consider

However, open source has a few down sides that your strategy needs to take into consideration. Open source projects like to take the “happy path”, ie in an ideal world where everything works and you can function in a self-contained bubble. Unfortunately, as we know all too well, stuff happens in the real world that we need to be prepared for. Here a just a few of the more critical areas that you should manage into your open source strategy:

• Fault Management – The ability to monitor project related systems, detect issue, log them with understandable errors, and create an API for external monitoring tools to pull the data is critical to reliability and availability.
• Performance Management – The ability to understand how your software will perform and scale and under stress is critical to the enterprise. Most open source projects do little to now performance or scale testing. This leave the enterprise left to profile, manage the underlying infrastructure, and ensure scalability.
• Security – This one always surprised me as most enterprise software developers are very security conscious and understands why security is import to their application. Threats, vulnerabilities, and best practices for secSDLC are not part of open source projects and as a result, the enterprise is as great risk when using open source and needs to fill this gap.
• Metering – Since open source software is not for sale it’s obvious why projects do not consider metering statistics that would be necessary to build a commercial offering. Unfortunately, enterprises are “for Profit” and require charging for use of their overall service, for which this open source project(s) is just one part of the overall architecture of the application.
• Integration – This is just bad software engineering. We know that components need to be connected to existing services – back office or operations. Open source projects should have an API to support basic integration patterns, but they do not. This is left up to the developer or business architect. In addition, continuous integration with updates and compatibility are always an afterthought.

Building an open source pattern for success

While these concerns are import to address, with the proper strategy and organizational rigor, defining a pattern for success can be achieved.  The following principals provide guidelines for building an open source program in your organization.

• Measurable – It’s important to define aspects of the program that can be measured. The success of the program overall should be measured by either adoption or increased sales/product views. However, this takes time, it’s better to start out with number of contributors, number of forks, community impact (number of “likes”) or Ecosystem (number of projects incorporating your project)
• Organizational Impact – Contributing to open source sounds great, and it is, however you need to understand the organization impacts. The impact will not only be in terms of the software develop team make-up, but also technical considerations in relation to intellectual property decisions, code support, and liability (refer to legal implications below).
• Happy path items need to be addressed in community – as a community we need to take action to create better testing practices, adopt system integration and testing practices, and define a common set of security and performance issues that projects need to address.
• Legal implications – It’s important to consult with your legal team or seek outside counsel with expertise in open source to develop a program to protect your company and your employees contributing code. There are several programs in place to model yours after.

For more information. Follow us in Twitter @CiscoOpenSource and check out our website often for valuable resources and information. If your @linuxcon #cloudnativeday in Toronto, come have a short stack with me and The New Stack at Cloud Native Day. See the #pancakeoverlordrobot print some @usemantl flapjacks and join us for a discussion about the great forces shaping the new galaxies of the container and open source ecoystem.

Share