Open Source development model is very powerful but needs to be well understood and properly deployed in your company.
This section will explain best practices of planning for, deploying, and managing open source software in your company.
Why is it important to contribute?
An open source ecosystem is based upon a win-win development model.
Automakers know very well that sharing the load of development with partners who are also their competitors is a sound business practice. They do this through one to one contracts on car models, platforms or engines. These contracts precisely define the roles and responsibilities of both parties and what they get from the cooperation.
What’s new in open source software model is that the win-win situation is not “contracted” in the same way. Open source licenses define some rules (see next section) but the development is based upon the good will of the many partners involved.
The biggest temptation of the open source model is to take useful software but not give back bug fixes or software your company has developed. You could get the benefits but no one else benefits from your work. But this approach is short-sighted and not as beneficial as it may seem. If you take a software component from an open project (called branching) and then you keep your modifications and improvements for your own, then you will have to maintain that branched software for decades. On the other hand, if you push your proposals of improvements to the community (called "upstreaming") and they get accepted, the code you wrote will be tested and improved by other engineers for free.
This open source ecosystem approach has proved its efficiency in several industries. But one should not neglect the need to change the cultural mindset when deploying open source in a company, plus the need to adapt some processes to this new way of development.
IVI Serial development projects are big machines involving hundreds of people and multiple companies over years. Organization, contracts, work breakdown structure are key entry data of development process that will guide behaviors of all parties along the project. These entry documents are prepared during the RFQ process when an OEM starts discussions with suppliers. People do not start from a blank sheet of paper to prepare these documents but use references that they have in their company. If we want to get the expected “upstream attitude” during development, the root document that describes how projects run needs to be updated accordingly. It is best that this root document is prepared before RFQ process. It needs to be confirmed in the organization description in the contracts all parties sign. The work breakdown structure needs to list such upstreaming activities so that the resource plan is defined accordingly.
During development, resource managers have to fight with daily difficulties; pushing bug fixes and enhancements into upstream projects cannot be their first priority. Managers will not allocate time to this important activity unless it is a standard established at the start of the program. The program management should make it clear that contributing back to upstream projects is a rock-solid standard in the company.
The key message to conclude: if you want to make your open source projects sustainable, make sure your company is organized to contribute.
Open source code may be free but it not free from obligations on the usage and distribution of the code. When the author of the code, who owns the copyright and any other intellectual property rights associated with the code, chooses to attach an Open Source license to his code, he has defined those obligations to anyone who uses the code.
Hundreds of open sources licenses exist, with a large variety of obligations to fulfill. For example, simple licenses mention the name of the author and give access to the Source Code by the final customer. Others add more obligations such as letting the final customer modify a product based on the code. The licenses also define the rules when some piece of code is modified : can it become commercial, should it remain open source code? There are also some tricky rules about code integration and some licenses may "propagate" to code into which it is integrated.
The important message is not to be frightened,but to realize that license compliance must be managed. GENIVI is not only a good example of sound license compliance management, but many of its members can help an organization plan for the open source processes that are essential to using and distributing open source software in a company's products. GENIVI has defined its own process to deal with compliance and has worked with Tier one suppliers to understand their difficulties and fears on this topic. GENIVI has defined its own licensing policy and works with preferred licenses. The License Review Team manages the licensing and legal activities of the alliance and is chartered to ensure that the technical work of the alliance is founded on legally sound approaches that are acceptable to the membership of the alliance and to the broader open source community.
During some GENIVI All Member Meetings, GENIVI will give a primer on how to work with open source software. Organizations like the Linux Foundation deliver courses on Open Source License Compliance. And GENIVI also has recommended partners who can also equip organizations with processes and tools to help establish license compliance.
GENIVI networking in the Open Source community is also very useful. GENIVI in the past could alert members that compliance issues were raised on a product and help solve these.