It takes considerable time to grow internal open source expertise. The goal from an enterprise perspective is to find people with enough peer recognition to be influential in the community. There are typically three pillars to this: domain expertise, open source methodology, and working practices.
Internal organization dynamics must be favorable to open source efforts. Implementing these practices requires a shift from traditional software development practices to a more open and collaborative mindset. As an open source leader inside
your organization, you will face several challenges in funding resources, justifying ROI, getting upstream focus, etc. These often require a major shift in mindset and a lot of education up the command chain.
These open source practices require an IT infrastructure free from many limiting IT policies and a computing environment that supports open source development.
Proper open source metrics drive the desired development behavior. Unfortunately, the traditional metrics often used in product organizations only apply in the context of open source development. For example, we have had multiple instances of the upstream implementation of desired functionality because of OSG developers that lobby for support from the community.
In this case, the number of changesets or lines of code does not matter as much, as the technical leadership team members provide to get code upstream and reduce our downstream maintenance efforts. The metrics we track account for things like this.
Organizations have transitioned from highly complex and cumbersome policies to a more straightforward approach for receiving, reviewing, and approving source code contributions. Dedicated open source teams often receive blanket approval to contribute to open source projects. This is not the case for other groups, which need different approval levels depending on the nature of the contributed code (e.g., simple bug fixes, code to improve existing functionality, code that offers new functionality, or starting a new project). This is a function of the balance between all parties involved: legal, engineering, and open source.
The organization must share information and priorities across different divisions. To illustrate this, assume you are on an open source team and request to support the implementation of a driver, but you cannot access the hardware manual and
instructions. This situation sounds a bit like playing darts with the lights off; therefore, information sharing is critical to successful internal collaborations between the open source teams and everyone else.
Focus your contributions on upstream projects that would directly benefit the organization's strategy and products. In open source development, it is easy to get carried away by hopping between different exciting projects. However, in an enterprise setting where the open source group is a cost center, your driving force should be to focus on open source projects that support product development. Open source teams often perform a yearly review of the product portfolio they support and focus their involvement on open source projects commonly used across as many products as possible. Such a methodology drives priorities and is a great way to remain focused on what's essential, justifiable, and fundable.
Be the upstream partner for product teams; they often feel like they are working inside a pressure cooker, especially in a consumer electronics environment. They often seem
understaffed, need more critical resources to support parallel upstream development, and are under constant pressure for feature delivery within tight schedules. In such an environment, it is easy to overlook the benefit of upstreaming in favor of short-term time savings, which can, unfortunately, lead to technical debt that has a higher cost in the long term.
Open source teams can help by being a partner that focuses on delivering the necessary code upstream, reducing this technical debt.
FIGURE 5
Design & implement with upstreaming in mind to increase the likelihood of patch acceptance.
Ensure the contribution improves or introduces functionality that is useful for a broad base of users.
Stay involved in upstream development post merging with the upstream project.
Document the code to make it easier to understand and to lower the barrier for new contributors.
Upstream for the right reasons.
Upstreaming is not a code retirement strategy.
Listen to feedback, and act upon it---rework the code based on the peer review process.
Follow proper coding style, and secure code guidelines.
Follow the processes set by the project for submitting code, new features, etc.
Grow open source talent in specific technology areas relevant to your products. Hiring a few resources from outside the organization is easy, but this approach has several limitations. The alternative approach is to convert your existing developers into open source contributors via training on the technical domain and open source methodology. You can then pair these developers with a mentor to further expand their skills.
Encourage developers outside the open source team to learn from and contribute to the open source community. We provide as much help as we can with upstream code contributions.
Still, we need more resources and sometimes need a deeper understanding of products that might be necessary to identify where we can adequately upstream code. Better involvement in the open source community from teams outside our own allows us to get more critical code upstream and improves our ability to interact with the community.