In Episode 4, the test automation team encountered unanticipated barriers to adopting the open source OpenTAP platform. To build confidence and overcome resistance to new software and a new lifecycle paradigm, OSPO lead Codie recommended a mix of internal evangelism and training programs. Codie was also instrumental in addressing lingering concerns from Legal about licensing and protecting company IP.
Advocacy by Codie, Gabriel, Francisco, and the rest of the test lab team paid off, internally with a decision to move towards production deployment, and externally, as the team’s experience is highlighted on the OpenTAP Forum and Codie is asked to pen a guest blog at blog.opentap.io.
Consumption to Participation
Everyone agrees that they’ve made great progress. However, such impressive business outcomes are not the same as fundamental change – the team needs the corporate culture to evolve to take full advantage of OpenTAP. A good place to start is changing the culture of consumption of open source code to one of participation in open source project communities.
Consumption is where most organizations begin their open source journey, because participating in an open, public community can be daunting. While more “eyes and hands” can mean higher quality code and lower maintenance costs, the exposure of company code to critics and competitors makes some companies stop short. While the stated concerns usually focus on losing control of intellectual property, the unstated ones come from discomfort with a development culture shift.
It’s important to realize that participation usually doesn’t begin (or end) with major code contributions. Participation activities also include joining in community forums, reporting bugs, suggesting features, writing documentation, sponsoring events, submitting patches to existing code, creating test cases and writing test code, to name but a few options. In the wide world of open source, relatively few organizations end up donating significant amounts of code, let alone business-critical code, to a project in which they participate.
Choosing a Participation Starting Point
OpenTAP features a highly modular architecture, with key functionality and extensions to its core delivered as plugins (Test Steps, DUTs, Instruments, Listeners, etc.). This modularity offers Gabriel and his team the opportunity to participate in the OpenTAP project with a narrow scope and consequently limited risk. Our heroes decide to publish a plugin that does not expose business-critical IP but does provide the OpenTAP ecosystem with useful new functionality, and Francisco gets to work. Examples of this type of plugin include a generic Device Under Test (DUT) or DUT template, a plugin to support a new or legacy instrument, or a listener with support for new data or document formats.
The Legal team is still hesitant, but finally approves a one-time contribution to the OpenTAP ecosystem. Inside Counsel reviews the OpenTAP Contribution Guidelines and executes and submits a copy of the OpenTAP Contributor License Agreement (CLA). Codie also promises to come back with data to help evaluate Risk-Return from the contribution.
Rapid ROI from Participation
Soon after Francisco publishes the plugin, along with documentation, on OpenTAP.io other community members begin downloading and evaluating it. One community member notices a bug in the plugin, fixes the bug and submits a patched version back to the project. All without taking time or effort from the original dev team.
Not only do group director Tanya and other company executives take notice, but this rapid return reduces remaining hesitancy from the Legal team for further project participation in OpenTAP and possibly other open source projects. Legal begins working with Codie on more flexible participation and contribution policies. Recognition of the value of participation also makes its way around the organization, along with acknowledgment that contribution needn’t carry risk to valuable company IP.
Collaboration is Contagious
After this first success, development, and product teams from across the company begin deploying and also participating in OpenTAP and to help maintain the OpenTAP platform, submit patches and develop OpenTAP plugins. Instead of building and maintaining purpose-built test systems, they can leverage and improve shared open ones.
Collaboration crosses department lines and brings together developers from companies across an ecosystem, even competitors, to share in creating and maintaining non-differentiating technology.
The results?
Faster time-to-market – reduced time spent “reinventing the wheel” and rapid innovation
Improved margins – QA / code curation become shared activities vs. fragmented, repeated ones
Lower defect rates – “Many eyes make bugs shallow” (Linus’s Law)
These results have a visible impact and are noticed by company management, ecosystem partners, and most importantly, customers.
Open Source – OpenTAP and Beyond
The OpenTAP team at Keysight, together with analysts/consultants at Open Source Sense, have created a white paper that examines the impact of open source on the Test and Measurement industry, and more broadly, the positive consequence of community-developed software on key end-user segments. The white paper focuses on benefits realized by equipment OEMs and test automation developers from the economics and technical velocity of open source software collaboration, based on the background, history, goals, and scope of OpenTAP.
You can download the white paper here.
To Learn More
Once you have your tests up and running. You need to be able to collect and store data. Learn how in the Results handling series below: