His talk "Improving the Impact of your Enterprise Open Source Development and Participation" will offer a practical guide to a number of practices that enterprises can adopt to help them grow their footprint in open source projects. Furthermore, the talk touches on the challenges enterprises face and how to overcome them.
What follows is some primer material to his OSSF talk.
Executive Director - LF AI Foundation
Enterprise open source development and involvement has its own set of challenges, but it becomes easier if you have a clear plan to follow. If you're one of the growing list of companies that relies on open source software for their products and services, investing time and money into improving your open source practices can pay off immensely in the long run. Fortunately, there are many success stories of companies getting involved and becoming leaders in various open source domains that they charted a path you can follow to improve your own contributions and aim for a leadership role.
BACKGROUND ON THE TALK:
3 top suggestions to Improve Your Open Source Development Impact
Open source development has its own set of challenges, but it becomes easier if you have a clear plan to follow. For instance, the Linux Kernel is the largest collaborative software project in the world, and getting involved in the development process can be a challenge. If you're one of the growing list of companies that relies on the Linux Kernel for their products and services, investing time and money into improving your internal development ability can pay of immensely in the long run.
Fortunately, since so many companies and individuals have been successful at contributing to the Linux Kernel, there is a pretty clear path on to improve your own Kernel contributions and aim for a leadership role. This practical guide will cover a number of practices that enterprises can adopt to help grow their footprint in large open source project using the Linux Kernel project as a case study.
Top Recommended Practices
1 - Hire key developers and maintainers from the project’s community
This critical step allows you to gain skills and recognition. Two or three people are a great start towards making a noticeable impact in a large project such as the Linux kernel, attracting further hires, and allowing enough resources to mentor existing junior developers.
You also need to align corporate interests with individual interests: it's very hard to motivate a senior open source developer to work when their personal interests don't meet with corporate interests in a given project. For example, a Linux memory management expert may not be interested in working on file systems, a corporate priority. Therefore, finding a match in interests is critical for a long lasting relationship.
2 - Allocate Time for Upstream Contributions
The core principle for hiring open source developers is to support your open source development and upstream activities. There is also the expectation that they should support product teams in their expertise areas. However, it's not uncommon for product teams to exercise their influence in an attempt to hijack the time of the open source developers by having them work on product development as much as possible. If this happens, many open source developers will head to the door, seeking a new job that allows them to work on their upstream project before you realize what just happened.
Therefore, it's important to create and maintain a separation of upstream work and product work. In other words, it's recommended to provide your open source developers with guaranteed time to meet their upstream aspirations and responsibilities, especially if they are a maintainer. For junior developers or other internal developers who are using open source in product components, such interactions with the upstream community will increase their language, communication, and technical skills. In the absence of such an upstream time guarantee, it's easy for these team members to be sucked into becoming an extension of product teams, resulting in their upstream focus drying up in favor of product development.
3 - Create a Mentorship Program
Set up a mentorship program where senior, experienced open source developers provide mentorship to junior, less experienced developers. Typically, the mentorship program would run for 3 to 6 months; during this time, the mentor should supervise the work of the mentee, assign tasks, and ensure proper results. The mentor would also do code reviews for anything the mentee produces, and provide feedback before the mentee pushes the code to the upstream project.
The goal is to increase the number of developers the company has contributing code to the upstream project, and to improve individual effectiveness by increasing the quality of code and the percentage of code that is accepted into the upstream project. Generally speaking, no more than 4-5 mentees should be assigned to a given mentor, and ideally they should work in the same area as the mentor to make code reviews more efficient.
These recommended practices, and many more, are the basis for Ibrahim's talk at OSSF, in addition to a discussion around required internal infrastructure needed to support open source consumption, compliance and contribution.