Part 1: Embracing open source projects while maintaining enterprise-grade standards for engineering and quality
This is part 1 in a series that shares the journey of F5 Networks towards becoming a member of the open source software community.
In the beginning…
A large number of established companies, including F5, produce software technology with origins in proprietary, or "closed source", software. To create products in a predictable and repeatable manner, we establish an array of business and engineering processes as well as tools. This constitutes the culture, from a technical perspective, of the company. Once established, the culture (good and bad) is resistant to change. You may recognize this as doing things the “<company>-way”.
But what if…
The open source community has a tremendous body of work available. The work ranges in scope from tiny building blocks all the way up to entire products. This can significantly impact the amount and flow of work required within a company. Ideally, this enables us to solve customer problems more efficiently or foster innovation when building on top of (e.g. computer operating system) or integrating with (e.g. OpenStack) an open source solution.
Fast-forward to today…
It is now common for products to leverage a hybrid approach; incorporate open source software prudently and focus engineers on implementing core intellectual property to create value for the customer. The final product has a varying distribution of closed and open source software, yet from a customer perspective there is a single point of contact.
What doesn’t change…
Enterprise-grade products carry with them certain expectations with respect to capability, quality and support. In general, customers should not know or care about the origin of our software. There is well-written and poorly-written code inside and outside of any company. That means, eventually, something will break or be used in an unexpected manner and the customer will require assistance.
The way forward…
There is no right answer for how much involvement a company should have with open source. A combination of internal (e.g. desire) and external (e.g. regulatory) factors will impact the strategy. Within F5, this has been growing as a grass-roots effort for the past few years for multiple projects and products. F5 integration into OpenStack started as a community effort with best-effort support from the community. Having real experience to identify what does and doesn’t work well (for F5), the grass-roots effort is evolving into a broader strategy with appropriate checks and balances. We are doing the right thing for our customers and the OpenStack community, having launched multiple fully-staffed, committed and supported products that serve as bridges from paid, commercial product into free, open source solution. Reaching this point took patience and due diligence; most notably that we, as a company, are not asking “if” but “how” we need to proactively manage open source engagements. Above all else, we need to listen to our customers so we can meet them where they are now and help them get where they plan to go with respect to deploying F5 products.
Being a champion…
Choosing the wrong starting point, such as deliberately hiding open source involvement, can easily trigger a long-term negative impact on building a successful relationship with the community. Here are the keys that led to success for F5 open-sourcing its OpenStack products.
Identify a suitable product: Pick a small product or project and team that won’t disrupt the business while learning how to work with open source and the community.
Identify key stakeholders: Locate the decision-makers that can support (or block) efforts to use from or share with community.
Develop the team: Empower the team to learn new tools, skills, and create processes geared towards an open source project.
Be transparent: Communicate openly with stakeholders, such as the legal department, to ensure open source actions do not put you, the company, or any shareholders at risk.
Be patient: There may be significant impact for parts of the company. Resistance to change does not mean rejection, but extra discussion and analysis may be required to bring everyone along.
