These monopolists were controlling the nascent automotive industry with the fear of lawsuits based on the Selden patent. Ford won his suit and formed a new automobile manufacturers’ association. The next step started technology “open source” as a concept. The association instituted a cross-licensing agreement among all US auto manufacturers. Under the terms of the association, each company would develop technology and file patents. Patents were shared openly and without any payments between all the manufacturers. For the next thirty years 92 Ford patents were used freely by other manufacturers. In return, Ford Motor Company used 515 patents from other companies - all without lawsuits or payments.


Skip forward nearly a century and the principles have remained, but now the technology has dramatically changed. Open Source is a seductive concept, but there’s a lot more to developing products based on Open Source:


  • Find a candidate Open Source package
  • Evaluate the source, how it’s maintained, development standards, license terms, and who owns your “proprietary” software
  • Evaluate the trade
  • Select an Open Source package
  • Create a development team and adopt compatible software development standards
  • Develop your product(s)


Open Source based code means finding it first. Source Forge is one of the larger collections of general Open Source software, some of which is appropriate for embedded applications.    Other general sources include and Open Office. More than 100,000 individual web sites also offer embedded “open source” software. Chances are that there are a small number of Open Source packages that are both accepted by your industry and meet your individual programming methodology. Articles in trade publications can provide a starting point to research Open Source offerings when combined with informational web sites like voip-info. 


Evaluation can be a time consuming process or a straight forward simple exercise. Practically, the chief difference in evaluation approaches is based on the size of your organization and the risk perceived in the software choice. Base criteria that should be considered when evaluating software include: industry acceptance, programming language used, Operating System requirements if any, coding standards used, code base maturity/stability, and how the coding standards fit with your organization. 


Evaluating the tradeoffs transcends the technology questions. Some of the issues center on business risk associated with the developers of the Open Source package. Most Open Source has a relatively small number of key contributors. Many companies have concerns over the relatively small number of people involved directly in many Open Source packages. This concern may be offset by a large installed base of the package, reducing the perceived risk by ensuring that there are programmers who understand the software.


Selecting an Open Source package is more than a technical decision. But making the decision often comes down to selecting between small numbers of alternatives. For example, there are perhaps a half dozen Voice over Internet Protocol (VoIP) packages available to develop Private Branch eXchange (PBX) products. To select a VoIP package, installed Open Source packages make one package stand out for having close to a 100 to 1 installed base as compared to the closest competitive VoIP Open Source package. Large numbers of installations often provide a strong indicator of technical competency. Even though the software may meet technical objectives, there are still the license terms to deal with.


For many people, Open Source is really about the initial acquisition cost – free. Today there are 68 separate licenses approved under the Open Source Initiative , each of which must follow the  OSI guidelines. Whether you select an approved OSI software project to use as part of your product, it’s important to keep in mind that this software code is licensed. As with any licensed product, it’s important to have a competent legal review of the license before deciding to base a project on the source.  Ideally the lawyer reviewing the proposed license agreement has significant experience with Open Source Software. This is particularly important because many business contract attorneys lack experience in dealing with Open Source issues.


Technical decisions drive the remainder of adopting Open Source.  Selecting an Open Source package makes a number of decisions for you and your company. One of the most significant decisions may be that of programming standards. Most Open Source is developed in a collaboration environment which may not match with your internal development standards. But if there is no requirements to significantly modify the source code, the development methodology need not be a significant factor. In these cases, it’s easiest to use the same development tools to generate the needed binaries employed by the developers. If those tools are not compatible with your product development environment, there will be source code modifications necessary to retarget the Open Source package. Retargeting source was the subject of another blog. There are a number of tool suites available for Intel embedded processors discussed in earlier blogs including Green Hills Software (1), Intel’s tool chain, Wind River Systems (2), QNX (3) and ironically - open source-based tools.


One of the fundamental bases of Open Source is the idea that additions or modifications to the Open Source code itself generally carries with it an obligation to make the modified software freely available under the terms of the open source license. The obligation of source ownership may be a significant issue in embedded applications, and is a question of licensing terms, the type of software to be developed, and how your development team is organized.  Assuring proprietary software ownership may cause companies to separate their development activities: source code derived from Open Source software in one team, and a second, segregated team developing proprietary software for inclusion in a commercial product. Other possible solutions to the ownership dilemma of Open Source include segregating personnel who have access to the Open Source, contracting with an outside company to deal with the Open Source software and producing only binaries for use in developing proprietary products, and other “clean room” software development methods.


The situation becomes more complex when multiple Open Source code bases are combined into one commercial product. Even with this potential complication, the problems can be managed to permit developers freedom to create new technical solutions for commercial products. The GENIVI consortium seeks to minimize potential for conflict by stops development before the application layer. By agreement, cooperative software development stops at the APIs below the application layer, minimizing the risk to proprietary software ownership. This is one way to deal with the very real issues facing commercial products based on Open Source.


Open Source can save development time and minimize the amount of knowledge required by developers to make ground breaking new products. Where can you see opportunities to use Open Source in your next project?    


(1) Green Hills Software is an Affiliate Member of the Intel Embedded Allaince

(2) Wind River Systems is an Associate Member of the Intel Embedded Alliance

(3) QNX Software Systems is an Associate Member of the Intel Embedded Alliance




Henry Davis
Roving Reporter (Intel Contractor)
Intel(r) Embedded Alliance