This article is excerpted from the book The Business and Economics of Linux and Open Source.
Open source fundamentally changes how you view human resources and organizational development. In this article we will examine the details of how the hiring process needs to change, the new qualifications that you need to look for, and some of the IP provisions normally associated with the hiring process. We will also examine the notion of the community as an extension of the organization and managing the organizational firewalls. Your goals for this chapter are to understand how to:
- Evolve your recruiting and hiring processes
- Manage the IP ownership among employee, company, and community
- Manage community leaders in your company
Hiring and working with the community of developers is a different process, but it allows you to know and understand who you are hiring and what skills they have very early in that process.
Employment Contracts
When you hire engineering talent that has been working within the Linux community and hold very strong beliefs about open source and free software, you will likely encounter a new request from these employees during the hiring phase. Such a prospective employee will be excited about coming to work with a company that is involved in open source projects. However, that person may also have very clear expectations that the only projects they will ever work on are open source projects. Your company needs to develop a clear set of policies governing existing and new employee hires. Your new policies should consider the following elements:
- Projects — Can a new or existing employee limit his or her contributions to open source projects? For large companies that know they will have long, sustained engagements with the community, this may be fine. However, if you expect employees to participate in proprietary projects, your policy needs to be clear.
- Copyright ownership — As you have learned throughout this book, even open source contributions involve copyright ownership. Your policy should dictate who is expected to own the copyright for contributions by your engineers. Is it owned by the company, the employee, or both? In most cases, the company should retain the copyright ownership (or acceptable license) to be able to implement dual-licensing should the need arise. There may be cases such as Apache and SAMBA when it will not be possible for your company to retain the copyright on contributions. These projects have policies that prevent you from retaining copyright ownership.
- Personal vs. company time — Many engineers will work on open source projects in their spare time. In some cases, the line between company-related work and employee hobby will be clear; in others it will not. In yet other cases, what an employee starts as a hobby project may evolve into a company-relevant project. You need to clearly define when and how your engineers can participate in open source projects on their personal time, and define the disclosure rules for your employees. Local employment laws may limit restrictions on your employees.
- Competition — Your human resources policy will likely restrict your employees’ abilities to work with competitors. One of the fundamental benefits of open source is that sometimes it is best to share the developments and costs with your competitors (within the limits of antitrust law). In these cases, your engineers may be actively involved with your competitors in development projects.
If your set of policies and guidelines covers these elements, you should be able to work on open source projects and take advantage of the talent that is available.
Participation Policies
Make it clear to your employees what the business objectives are. Some engineers will need to be reminded that your company is in the business of making a profit. Even if they work on a project that will not generate direct revenue, they should understand where the business intends to make money (e.g., support, services, hardware, etc.). A clear communication of your business model will help your engineers ensure that they participate in the most effective way possible with the community, while applying the right degree of judgment when decisions need to be made on where the lines between open source and proprietary software need to be drawn.
You also need to define your behavior with the community. What are the acceptable licenses that a project must have for employees to participate? If you work on Linux kernel projects, what will be your policy on proprietary and open source kernel modules? In short, use the elements of this chapter, and the other elements you have learned from the rest of this book, to develop a comprehensive open source policy and strategy that define for your employees and the community what your expectations are for a respectable code of conduct and how you intend to partner with the community.
Hiring the Right Person
During the hiring process, you are trying to assess if an individual is a fit as a new employee within the organization. There are now an additional set of criteria you need to look for in a prospective candidate. This list does not replace your standard hiring processes. You should consider these additional criteria to evaluate during the hiring process.
Technology
Each technology (Linux kernel, file system, Web server, device drivers, networking stacks, etc.) area will have a sub-community. Although your prospective candidate may not be well-known in the larger community, a prospective employee may be one of the best-known developers for the area you are looking for. Therefore, do not focus so much on overall notoriety in the Linux and open source community, but look for respect within the focused sub-communities you care about. Contact members of that sub-community and get to know who the players are.
Community Home
Each project has a maintainer. The maintainer is responsible for accepting or rejecting contributions to the source base and deciding when a release is appropriate. New communities can spawn from disagreements between a maintainer and a contributor, an event referred to as “forking” (although this is rare). This can be the healthiest part of the open source process. However, there are cases when competing projects are not desirable (such as the Linux kernel). The better maintainers will have a proven track record of resolving conflict and focusing all the development energy for a given technology area on a single project. It is possible for you to hire the maintainer for a given project. You will then need to balance your needs for that individual carrying out their company duties and their responsibilities to their community. Is your company able to deal with a situation where the maintainer/employee makes a decision that is right for the open source community but disadvantageous for the company? Do not assume that because you hire the maintainer, you control the project! Recall that Linus is the maintainer of the Linux kernel, not his current employer.
Maintainer or Contributor
As you now understand very well, most open source projects are characterized by having a maintainer and a community of contributors. You need to have a clear understanding of the role you are trying to fill. You will only need so many chiefs, and having a strong pool of contributors is critical to your success. Finding individuals who have experience in making contributions in many different technology areas will be a big plus. They will have a clear understanding of how different communities operate, and they will have been exposed to a number of different maintainer styles. It is a good idea to contact the maintainer of any project a contributor has been involved in to gauge the quality and value of those contributions.
If you decide that you need to fill a leadership role, look for someone who has previous experience maintaining an open source project. As a maintainer, test some of the following leadership characteristics:
- Does he/she recognize and give credit to key contributors?
- How does he/she resolve conflicts between contributors?
- Has he/she seen competing projects created as a result of not resolving conflict? Was it the right outcome?
- Has he/she been able to attract key contributors to his/her project?
- Has he/she developed release processes?
- What process does he/she use to determine that a project is ready for release?
- Can he/she give examples of contributions that were better than his/her own implementations?
Maintainers are a special breed of individuals who combine technical skills with the ability to interact well with other developers and guide the development of a project.
Community Visibility and Respect
The ability to drive an agenda within the community is dependent on the degree of active involvement and real contributions to the project. Recall that control is with the maintainer. The maintainer of the project will be influenced by familiarity with the individual(s) making contributions, plus the quality of those contributions. Does the prospective candidate have positive visibility and respect within the community? To determine the level of respect and visibility, look at the online interactions your candidate has with the community (e.g., mailing lists, archives, etc.).
Online Interactions
Once you understand the community(ies) that your candidate is involved in, and you believe you have a strong fit with your specific needs, spend time understanding how the individual interacts with others online. Online interactions will be the primary vehicle for communication with others. It is vital that the candidate is able to wield influence with others in disparate time zones and cultures. Here are some things to look for:
- Ask for, or go to, email archives and examine the interactions. Look for the interaction style of your candidate. Does it fit with your company’s culture, and does it appear effective in getting contributions accepted?
- Discover what pseudonyms your candidate uses online. Look at the archives at SlashDot and other online locales. Does your candidate hide behind secret pseudonyms to trash other individuals? Is there passion without condemnation?
- Does your candidate initiate discussion on useful, compelling topics? Or, does your candidate only respond to others? Are the responses constructive?
Attempt to determine the respect your candidate has by looking at how many seek out his/her advice. Also examine how readily contributions are accepted by other maintainers. Someone who has developed respect within a community will be able to get his/her contributions accepted with virtually no debate.
Contributions
Request a detailed list of actual contributions to a variety of open source projects. When evaluating candidates from competing companies, it is not possible to request actual contributions to proprietary products. The beauty of open source is that everything is open and public. You have the ability to measure the quantity, quality, and technical capability of your candidate before ever hiring. Your managers and other employees are a good source to use to analyze historical contributions and give you the feedback you need.
Also look for the style of contributions. Does the candidate make tactical contributions to solve specific problems and patch specific issues, or does he/she get involved in architectural and design discussions? The style of contributions should fit the needs of the position you are trying to fill, as well as build your bench strength for leaders of the future. For example, if you are trying to fill a support position, someone who has the ability to find problems and fix them without negatively affecting the overall system can be very valuable. However, if you need to find someone who will be a maintainer and guide architectural direction, you need to look for someone who has a track record of identifying and acknowledging stellar work from others.
Geography
Anyone with experience in working with the open source community will be capable of working and interacting with people across geographies, time zones, and cultures. The challenge for the hiring manager will be to develop a geography strategy for talent acquisition, as well as where the talent resides after hiring.
It can be a great benefit to your company to be able to hire talent from anywhere in the world and have them join your team. However, this will need to be balanced with the obvious benefits of having a co-located team that can work closely together. From my experience, one of the best strategies is to ensure that you have a strong critical mass in one location for a given project. Avoid splitting projects across geographic boundaries. Then you can add specialized, high-caliber talent in remote geographies that supports and enhances a local team. The other benefit to this is that when your team works with outside community members, it manages the relationship to remote company members virtually the same way as community members.
If you are contributing to an open source project that is critical to your company, consider funding a face-to-face meeting on a periodic basis for the key members of this community. This is often called a “hackfest.” If you can plan this around an industry event related to the business, then you can bring all the developers together to learn about the industry, get to know each other, and get some serious development accomplished. Plan to pay for airfare, hotel, meals, and all the usual expenses that a regular employee would have. You will generally find that community participants are frugal and more interested in getting development done than wasting your money. Your goal should be to get through a critical development crunch by supplying all the equipment the team needs. This way, the co-location and resultant collaboration will yield significant results.
Count the Hops
A community is largely driven by influence. The ultimate point of influence is the maintainer of a project. For large projects, there will be an informal hierarchy of trust between the maintainer and key contributors. Obviously, it is not realistic to always expect to be able to hire the maintainer of a project. In the hiring process, discover and understand this hierarchy and then count the number of developers between your prospective hire and the final control point, the maintainer. This is known as “counting the hops,” like one does in network traffic routing. The less hops, the closer the candidate is to the maintainer.
Structuring the Teams
Structuring your teams will largely depend on the role your company takes in an open source project. As you learned from the corporate bazaar concept, it is possible for you to structure a very large open source project and manage the team. More often, you will be working on much smaller projects; in many cases, you will be one of many contributors to an open source project.
Because of the reciprocity issues outlined in the previous chapter, you should make every effort to keep developers contributing to external projects dedicated to open source projects.
The special case of gated communities will also come into play when structuring your development teams. You may find yourself with a combination of proprietary projects, open source projects, and projects within gated communities. It will be up to you to ensure that you have defined detailed processes to ensure that IP ownership and developer assignments are clearly defined for each of the boundaries.
Summary
Structuring, building, and managing teams that combine open source and non-open source projects is a different way to manage engineering teams. Culturally, your engineers will struggle between their loyalty to the community and their loyalty to the company. You need to be aware of this cross-loyalty challenge that many of your developers will have and get accustomed to managing it, and not feel threatened by it. This chapter gave you the new items you need to consider as part of the hiring and management process, and the elements you should consider as part of developing company policy.