More and more companies are adopting open-source Linux software as a way to gain competitive advantage. Linux is emerging as one of the most successful open source software adopted by many products ranging from servers to embedded products.
Recently Linux is emerging as an important mobile platform and is increasing its percentage of market share in a faster pace with major contribution coming from Android.
Thus an increase in need of Linux platform means companies move engineering resources from proprietary platforms to Linux based platforms to meet the market demands. A shrink in proprietary software means engineering resources have to migrate from proprietary development to Linux platform development.
For many, changing and adapting to a different environment would be a difficult task. But this migration can be made easy by attacking the key challenges engineers face and facilitate a smooth transition. This article discusses some common challenges engineers face migrating from proprietary environment to open Linux environment and possible solutions for it.
Generally proprietary software are developed by few selected individuals of a business unit and maintained locally. Thus the knowledge about the software, more importantly the knowledge on design decisions will be available within the team. Any information on the system is available locally
On a contrary open source system like Linux gets contribution from diversified team working across from the globe. Knowledge base for Linux modules is available on the internet generally as mailing lists archives. To get the necessary information one need to search in the archive with right keywords to retrieve the necessary information.
The first step to build the necessary knowledge base is to start subscribing to the mailing list and follow the mail chains activities. Senior members of the team who are in charge of technical decisions should take a lead role to read through the archives and build the necessary knowledge base and help team members to make design decisions. They can get in touch with the kernel maintainers of a particular module to get additional insights on the module.
One key factor that increases an engineer’s productivity is the debugging environment and related tools available for the platform. When engineers work on a platform, generally they get accustomed to platform’s development environment and find it difficult to get adapted to a newer environment. So when they migrate to a different environment like Linux it is important to educate and train on the new tool sets available on the newer platforms.
Linux kernel provides essential debugging framework like debugfs and other tracing tools that facilitate debugging. For example Linux kernel provides debug framework that can provide the user with function tracing or providing protocol tracing like in case of USB driver framework.
To ensure that engineers adapt faster to the debugging environment a simple hands-on bootstrap training on the debugging tools available and the how to use them can be conducted by senior members of the team.
In a proprietary development environment release management, setting up its pace and the feature to be delivered is totally controlled by the team. Any change done to the product can be made available in the subsequent release on a desired date.
In an open source development like Linux the speed of release and changes to be included is managed by kernel maintainers. The kernel maintainers are responsible for integrating the changes and release the next version.
If suppose you begin porting a Linux version to a platform, by the time when you stabilize the platform with a kernel version the community would be three to four versions ahead of you. You need to upgrade the kernel to the latest version and this would be a humongous task to again stabilize the platform with the latest version.
Such porting tasks are very unlikely in proprietary systems and thus it is important to allocate proper resource to upgrade your platform’s kernel with the latest kernel. It is a good practice and also provide good dividend when module owners keep track of changes in kernel activity. Such practices will help minimize surprises when migrating to the latest kernel.
Way of working and Ideology
A software product development is highly influenced by the way of working of the team and the cohesiveness. When developing proprietary software generally the team members know each other well and the way of working is adapted to the organization culture. On a contrary the way of working on an open source environment is totally different where one needs to establish trust and have to get to know other developers of the module.
It is important for developers and managers to participate Linux Conferences to get to know the fellow developers. It also helps to understand to the path ahead and get to know the module maintainers expectations. Keeping active in the mailing list by contributive with effective comments will also help to establish necessary trust within the community.
Another important ideological difference between a proprietary software and open source development is how Intellectual Property (IP) is managed. In a proprietary software development IPs can be easily implemented or integrated as the software product is generally provided as binary. Open source ideology propagates free software products and proper care to be taken to ensure that company’s intellectual properties is not compromised.
To avoid any such compromise, companies can adopt processes that involve legal teams which would ensure that codes that are contributed to the community do not violate any of company’s Intellectual Property.
Tools and Guidelines
When a product is developed and subsequently maintained in-house, the process and project guidelines fall in line with the organization culture. A developer working on such an in house product will get hard coded with the review process, coding style and defect tracking mechanisms formalized by the company culture.
When a developer migrates to an open source Linux platform development the process is completely different. The developer needs to pick up the new methods and related tools that are mandated by Linux.
One another important information is the way software modules are designed. In case of a proprietary system any design decision on the product is totally within the team and finalized by senior members of the team. But in case of an open source development like Linux design changes needs to be reviewed by the community and requires consent from the community.
Linux provides documentation that details procedures to send patches, coding styles that are specific to its operating environment. When engineers migrate from proprietary platform they should be educated on Linux way of working using these documentations.
Also members of the team should participate in Linux forums and have face to face interaction with other kernel developers and maintainers to understand the community expectations.
Rajaram Regupathy is a Senior ACM member and author of the book “Bootstrap yourself with Linux-USB Stack”. He has a decade of experience in the embedded system domain including proprietary and Linux based systems based embedded systems. You may reach him at firstname.lastname@example.org .