As a software professional, are you a fan of open source or commercial development and testing tools? Or, do you rely on both?
Little more than a decade ago, many organizational decision makers frowned on open source tools, and software developers and testers often had to sneak them in the back door. Open source tools offered (and continue to represent) real value when teams needed to plug compatibility gaps, develop quick customizations, and otherwise accelerate their development and testing capabilities. Yet, corporate leadership viewed them as unknown quantities—mavericks that hadn’t proven their value over time.
With the rise of agile methodologies and the importance of continuous development and continuous integration, open tools became even more valuable, and those barriers began to erode. Now, development and testing teams use open source in firms large and small.
Even so, open source tools don’t work for every situation. Commercial development and testing suites still play an important role. Fans of both approaches often bristle at the idea that the “other side” has the answer, and I’ve seen developers and testers stubbornly refuse to accept that there is a place for both types of tools. In my opinion, letting go of that mentality and evaluating all options without prejudice or scorn is the best way to produce great software.
Keeping It Short
Open source has become a building block of attainment for organizations striving for short sprint development cycles, such as those using agile methodologies. With agile and continuous methodologies, developers check in code frequently, and testers work in lock-step with the development team. They build tests while development is in process rather than writing them for five to ten new features at once.
Testers perform their tests quickly and in parallel, as much as possible, providing the feedback developers need to correct code right away, helping to meet quality assurance goals. Rapid feedback loops do more than enable faster problem resolution and keep the sprints on track. They also make it easier and more efficient for developers to address bugs, since the code is still fresh in their minds. Although there are a few examples (AppDynamics and Hewlett Packard Enterprise StormRunner Load, to name two), commercial software generally is not designed to provide rapid feedback in the minutes or seconds required by continuous methodologies.
Furthermore, when new languages and protocols come to the fore, developers and testers using open source tools are able to embrace them, customizing the tools on the spot if necessary. This approach isn’t feasible with commercial tools. Since most commercial tool developers charge based on run time, they must limit their offerings to a finite number of languages to remain profitable. When these firms do add support for a language or protocol, the process can take years, and there are often large feature gaps between languages.
Staying in Sync
To work as efficiently as possible, everyone on the agile team must stay in sync with one another—everyone needs comparable training and should be able to code in whatever language the team is working on. With open source tools, frequent driver and system updates make it easier for the tools to stay up to date with rapidly evolving web browsers and technologies, as well.
To support this framework, enterprises employ highly technical talent who are more likely to be abreast of languages and protocols and have the mental flexibility to work with continually updated tools. This increases the cost of the development and testing resources, but organizations recapture that expense in the long run with better software quality, faster time to market, and greater user satisfaction.
With that said, the size of software teams will have an impact on how well this approach works. It’s practical for a single team of five or ten—or even a few teams, to stay in sync with one another, in terms of training. For multi-national corporations with development and testing teams of hundreds, if not thousands, such synchronicity is impractical to achieve. In these situations, consistency of effort is more important than speed. Here, commercial tools—or at least commercial options paired with open source—can be a more suitable approach.
Satisfying the Boardroom
For enterprises that rely heavily on statistical reporting on team and individual performance, open source tools alone will likely not be the best choice. Commercial tools provide a wealth of reports that are geared for large distributed teams with plenty of meta-data to report on. This central location provides the data streams for roll-ups, enabling organization-wide statistical analysis, visibility, and reporting.
To achieve this same result with open source tools generally requires either pricey, custom business analytics, custom coding by the in-house team, or tedious manual effort using traditional tools such as spreadsheets. Manual methods are especially impractical, as they can make the entire reporting effort slow and defeat the very goals of agile and open source.
Bits and Pieces
Open source tools have a few other drawbacks. They rarely work with legacy environments, and when enterprises use a combination of manual and automated testing, open source makes management and tracking more complicated. Finally, open source tools don’t offer the documentation and support that commercial tools do. For organizations 
with large teams of low-level developers and testers, those resources can be invaluable.
This isn’t to say that open source tools are not a good option. As we mentioned earlier, in fast-paced, agile environments, as well as for cloud- and web-based development, open source tools shine. In very large or traditional environments, commercial tools are often required to support the spread of technologies.
In the final analysis, I predict that open source will raise the bar regarding expectations for commercial tools. The vendors who rise to the challenge and provide more than their free counterparts will thrive, and the tools that are weaker than open source tools will disappear. All of this will lead to making much better software—products that are easier to use than at any time in the history of technology—available to solve real business problems.
