To an embedded application developer, open-source software seems like a fantastic option, whether it is used as the basis for an application or if open-source tools are used to accelerate the development process and speed time to market. Open-source software is, by its very nature, free – meaning without cost or payment. In an environment where managers are constantly trying to limit the costs around development, open source sounds like a great idea, and depending on each developer’s unique situation, it could be just the solution needed to address budget constraints.

Consider a few of the pros. First, open source is easy to acquire. With open source, developers just download and use the software. Code quality for open source can also be a positive. If the code is already decent, it will only improve as the community improves upon it. Leveraging the open-source community for help, support, and feature development is one of the greatest assets of open source. The feeling that “we’re all in this together” helps all boats rise.

Taken together, these benefits can make a developer wonder if a downside to open source exists. As it turns out, open source does have hidden costs that only become apparent once an organization is in the thick of the development process. While open-source products may be the right fit for some developers, others using open source can experience a variety of pitfalls after it’s too late to consider alternatives.

Let’s review open source’s impact on four key parts of the development process – using open-source code as the basis for developing embedded applications, customizing open-source platforms to accelerate builds, open-source sprawl and visibility, and support for time-sensitive issues.

Customizing open source for embedded environments

When considering open source to serve as the basis for a network infrastructure platform, set-top box platform, medical device, or any other embedded application, consider the amount of customization required to address the specific industry’s needs.

When implementing a new open-source project, a team either needs to customize the software to fit the needs of their environment using valuable resources from their own team or use funds to bring consultants in to do the same thing. The consultant route can save time that would have been spent customizing the software, but it still requires developers to spend time managing the process.

Maintaining open-source software is another time sink. Nine times out of ten, scripting and fixes are doable but come at the cost of developer hours that could be spent more wisely on developing the product, not just fixing open-source software. With the high costs of developers, that could represent a significant portion of development resources allocated to the “free” solution.

Optimizing open source to accelerate builds

Developers need to optimize their builds in a way that maximizes the productivity of the engineering organization. This means developers don’t sit around waiting for their individual builds to finish – a process that can typically take minutes or hours at best and days at worst. Build accelerator tools on the market today speed builds primarily through a process known as dependency-aware parallelism distributed across large-build clouds as well as clever caching and avoidance techniques, enabling fast and reliable incremental and full builds. Some large development organizations have optimized data centers employing these accelerators to speed builds for distributed global teams.

Open-source options are available for managing and accelerating software builds, but they entail clear limitations and caveats. For example, when using common software construction tools such as GNU Make and SCons, it’s typically costly to build in the necessary scalability and reliability to support and accelerate software builds at the appropriate level. This problem multiplies as organizations scale up to more developers, more projects, and a greater need for faster feedback loops throughout the development life cycle.

Another common problem with open-source build tools is the lack of visibility and “debugability” of the inner details of the software build structure, resulting in costly manual maintenance and long lead times for an organization looking to become more efficient and agile. The visibility to go back and identify what went wrong once the build failed simply isn’t there. As multiple teams combine their efforts to bring a product to market, this lack of visibility across teams slows down troubleshooting and therefore the ability to speed time to market. In an industry where time to market is everything and, increasingly, multiple releases and fixes for the embedded application are required, this level of support simply isn’t acceptable.

When considering alternatives to open-source tools, teams should ensure that acceleration tools don’t lead to broken builds, can leverage their existing hardware resources for parallelization, and can work with their existing toolsets and processes. 

One such alternative is Electric Cloud’s ElectricAccelerator (Figure 1), which executes parallel builds on a single machine or across a cluster of standard servers, reducing full or incremental build times by up to 20x. The key to this acceleration lies in patented dependency management technology, which detects and manages dependencies at the file level to ensure accurate builds. ElectricAccelerator plugs into existing build and release architectures, without the need to modify existing build scripts and tools. As an add-on to the build tool, ElectricInsight provides an intuitive, graphical representation depicting how the builds are structured and run, giving build managers the ability to pinpoint performance problems or conflicts across all of their builds. Instead of manually pouring over thousands of lines of build output files, error detection and performance tuning can be done in seconds.

Open-source sprawl and visibility

Because open-source platforms are easy to acquire, most departments end up implementing their own individual versions, often customized to meet their specific needs. For larger organizations, this can mean dozens of instances of continuous integration tools implemented within the same development organization, creating an unmanaged, siloed environment, or in other words, an open-source sprawl.

The resulting costs from such sprawls can be significant. First and foremost, this is not a model that scales easily. Second, management has little to no visibility as to the progress of the development effort. With a lack of standardization, there’s no way to truly assess progress or troubleshoot problems across interdependent projects. From a management standpoint, this is frustrating because efforts are uncoordinated and requests for costly resources come from all directions.

Open source and support

When using open source, developers always face the question of support. When time-critical issues must be resolved, the questions may need to be directed to the community because there is no official support system. Mission-critical applications that affect an organization’s revenues must be solved in a time-sensitive manner in collaboration with professionals who can be held accountable. There is something to be said for having someone on call on to fix a problem instead of relying on a community.

Taken together, all of these issues can easily compound to introduce significant issues in any embedded development process. That’s not to say open source can’t be a valuable tool for the embedded developer – it most certainly can. However, the cost of using open source for development efforts comes with limitations and requires time and effort for which organizations must budget. So when developers decide to depend on open-source technologies, they should make sure they’re aware of the true price of “free.”

Ashish Kuthiala is head of product marketing at Electric Cloud.

Electric Cloud [email protected] www.electric-cloud.com

Follow: Twitter Facebook Google+ LinkedIn

Follow: Ashish Kuthiala LinkedIn