 Hello. My name is Jeff Rowe. I'm a Program Manager for the Linux Foundation. In case not enough speakers have said so already, I want to welcome you all to the Open Source Summit Europe and its many co-located events. I am unfortunately not in Europe right now. I was given the opportunity to stay home and provide this talk virtually thanks to a certain virus we've all come to know. I am however lurking on the chat for this talk, so please feel free to interrupt by asking a question. Bear in mind that it is 6 a.m. on the west coast in North America, so I may be typing slowly while holding my coffee cup in one hand. I'm here today to talk about the roles in Open Source projects and the responsibilities that come with those roles. Understanding how things get done in a project and how the workload is shared can make the project more healthy and more flexible and can give everyone the room to grow into an effective leader. The whole idea for this talk started a few years ago when I was tasked with coming up with a job description for myself as a Community Manager. I've worked in Open Source almost continuously in some capacity since 1992 and I've held leadership roles in several Open Source communities. I've been filling the Community Manager role for several years across four projects at the time I was thinking about it. And during my career I've worked in program management on technical projects, operations, IT, membership support, marketing support, community support, and business development, as well as being an individual technical contributor for a number of projects. I wrote what I thought was a fairly comprehensive talk for the Open Source leadership summit in 2017 and I want to thank the eight people who came to see it. As I've been at the Linux Foundation now for a year and a half working flat out on two major projects as a program manager I thought it was time to update the talk. I thought this should be a no-brainer, right? Just write down what I do and what I'm responsible for and make sure that those two lists are equivalent. Well, it turns out it's more complicated than that. If I try to nail down what I do in a typical day or week and I have tried I quickly realized that at least as I have defined this role there are no typical days or weeks. Maybe that's just my personal melodramatic style and I'm prepared to accept that although I suspect it is simply the nature of Open Source projects. In any case, I believe it is important to articulate the standard roles with associated responsibilities within Open Source projects that can be generalized so that we can readily identify problems and gaps. Also important to me personally, I want to know whether I actually understand my job and its expectations, where do I fit in and am I the right person to be doing those things. These are the questions I want to answer with this talk and possibly to spark a conversation about who does what and how we can improve on that. The Linux Foundation lives on the forefront of collaboration in software development and nowhere is this more evident than in the Foundation's collaborative Open Source projects. Balancing the principles of open source with human and financial resources from project members and their sponsorship each project has a unique set of needs, resources and values. The lineup of roles in each project is similar but how those responsibilities are met is often a puzzle. One note, I will sometimes refer to foundations in this talk as a superset of projects. In essence, some Open Source projects are just one thing. The Zephyr project, for example, is a single operating system with a lot of moving parts, but we still refer to it as a single project and it has one technical steering committee. LF Energy, by contrast, has several individual projects, each of which has its own technical steering committee and the chairs of those committees attend an overall LF Energy Technical Advisory Council or TAC. So a foundation is a project of projects, including the Linux Foundation, which is a foundation encompassing well over 200 projects and foundations. The hierarchy of roles is the same for each project, though. I have worked with project leaders of all sorts and seen this puzzle take shape, often with leaders emerging from unexpected places. In this presentation, we'll talk about the roles that normally fill them, the gap-filling roles that also appear and can help point toward those emerging leaders. In particular, what I've found is that in Open Source projects, sort of like in startups, the balance of roles often calls for one person to bridge a number of roles, which calls for a certain amount of load balancing among expectations, stakeholders, understanding who's asking for what, setting relative priorities on specific tasks and projects and so forth. Certain personalities who are often drawn to the vibrancy of Open Source projects are also prone to taking on more than they can handle, which can lead to the unending to-do list and the eventual burnout. So balancing the roles in an Open Source project can require a different mindset from just balancing a job. I like to call this the work-work balance, and I really like this particular image for two reasons. One is that it shows clearly that balance itself is a point between two extremes, and you can't occupy both extremes at once. The other is that volume is also included, and when there are a lot of projects and not enough hands to help balance the load, you really, really have to address volume as well as balance. Now let's talk about these roles. For the purposes of this talk, I'd like to draw some arbitrary lines around different types of roles in projects as activities that are performed by people to do two things. To fulfill project functions and to achieve the goals of the project. Each role in every project has a vital role to play, and none more than the last two on this list. Contributors and everyone encompassing the entire community, industry, universe, or however you want to say it. In this talk, we are going to focus on the leadership roles, and those are the ones that are most likely to need to be filled either by the stakeholders who are those community members with a financial or strategic stake in the project, or by hired staff, often through business collaboration with a management services provider like the Lenox Foundation. I realize this is review for a lot of you. The purpose for going over these roles is to eliminate gaps that you may have in your project. Most are very similar to business roles in corporations with some notable differences and sometimes some different names. Starting with project functions, we can break these down into three silos, as shown. The column over on the far right will show where these functions should be resourced from the members, which usually represents the community or project stakeholders, from the project itself as a direct hire or contracted service from a foundation, or from the overall community because sometimes roles are filled from the larger community. Funding from the project itself is always nearly outsourced in order to provide a neutral asset who has no preference for any specific member. So these tend to be administrative and leadership roles that need to be neutral. As we go through these, also note there is a distinct division between technical and business-oriented roles, which is considered to be a best practice. So we will be going over executives, the decision makers. These represent the final decision points in many cases, as well as the decision-making body that manages a project's finances. This is your board of directors, the project treasurer, as well as the top most technical leadership. These also include the executive director, C-level and V-level folks. There is the administrative roles, the implementers of the decisions made by executives, and often the drivers of ideas for new initiatives. These include the directors and other strategic hire management. And then there are the managerial roles. They manage technical execution based on guidance from administrators. These are all the managers, the program managers, project managers, marketing managers, and as well as their technical counterparts, the maintainers, the task group or committee chairs, technical program managers, and those straddling the line between business and technical, which are namely the community managers. At this point, as we dive into each of these roles, I want to remind everyone that we are talking about roles here, not people and not jobs. One person might hold down several of these roles, while some roles are complex enough that they require several people to run them effectively. In addition, none of these roles have any greater importance or status than any other. All are critical or they wouldn't be on this list. So let's dive in. Starting with the executive roles. As I said earlier, these are leadership roles that are primarily filled by member representatives because members are the primary stakeholders in projects, and this is the table where they get a seat. The exceptions are for roles that need to be filled by a neutral person, and we'll go over each of those. First, the TSC Chair, Chief Architect, the Nevalent Dictator for Life. There are a number of names for this role. This is the technical leader of the project. The person who has the final say in everything about the project from a technical standpoint. This role goes by many names with slight nuances. A principal developer or chief architect is usually the final arbiter and often the big picture architect for the project. Sometimes that person can be a benevolent dictator for life, which is a sort of a funny term that is used in the industry to indicate somebody who is in a permanent position and always has the project's best interests at heart. Contrary wise, a TSC Chair is sort of a first among equals role that is nearly always filled by somebody in the community and nearly always rotates on a regular basis. One thing that's common with these roles is that they attend board meetings, taking guidance and direction from an advising board, and they function as the glue between the business and the technical sides of the project. It's a key role that is often filled by a member representative when a project first starts out, but as the project gains in stature, the need for this person to be in a neutral position becomes much stronger if the project can support that person as a direct hire. So I was recently asked by a board member how I would encapsulate the specific responsibilities of a board member or a board chair. Surprisingly, there's little written on this subject, although Red Hat's Deb Bryant gave a great talk at the 2019 Open Source Leadership Summit in Sonoma on this very topic. A board seat is obviously an influential and important position to hold. Most larger projects have a governing board or board of directors, sometimes called governing board advisory board. The fundamental aspect of a board is that it is representative. So board seats are held by member organizations, some directly and some through representation of a member level, such as a single seat representing 10 or 15 general members. Boards generally meet monthly or quarterly. They're usually defined by a project's charter or articles of incorporation or internal regulations or whatever is appropriate for the legal entity. So a board member's duties are usually called out in the charter. As a legal requirement, detailed minutes are usually required to be taken and distributed by a board secretary, which is a role we'll discuss in a few minutes. Board members are expected to attend and participate in all meetings, bring their industry experience to the group for the benefit of the project, to seek consensus and agreement with others, finding common ground where possible. That's definitely a best practice. To represent their group effectively, whether it's a company or another group of members, to balance the needs of their group with the needs of the project and to vote appropriately for the benefit of the project. The board chair has additional expectations, usually outlined again in the charter, and these often include organizing the agenda for each meeting, distributing the minutes prior to each meeting, directing the board secretary on what should be kept in the minutes, holding operational votes to approve minutes, as well as strategic votes during meetings or as issues arise, to preside over meetings acting again as a first among equals and a guide for discussion, to manage any day-to-day operational decisions, and to ensure that the treasurer and other chartered roles get the resources that they need and report back to the board. Speaking of chartered roles, let's talk about the treasurer. Treasurer is responsible for managing the project's finances on behalf of the board. As with other leadership roles, this does not mean they approve every expense, usually. Rather, it means that they manage the budgeting process and advise administrators on how to take in and spend money in accordance with the project's charter, including the ED and the program managers and other roles that spend money. The expectations for the treasurer role usually include representing the budget to the board and reflecting the board's interests in the budget, working with administrators to craft budgets, usually on an annual basis, and to track them from meeting to meeting, to meet with the executive director or CEO or whoever the head of the project is a week before the board meeting to go over the current budget. To present the budget to the board, along with commentary and to field questions from other board members regarding income and expenses, and to remain available as an escalation path for any unexpected expenses or income that arise. And one thing that's important to say is that very often that those specific duties are shared with an executive director who might have more experience with the hands-on day-to-day operation of a project than a treasurer might. So, a technical director. This is a primary actionable technical role in a project, the one who takes the architectural ideas and turns them into specific actions for managers and contributors to perform and who fields incoming patches, feature requests, bugs, et cetera, or more likely establishes processes for other people to do those things. This is the technical leader's vice president. The technical director role is distinct from the architectural role or for the TSC chair, although it's very often the same person. If the technical director is a separate person, most of the time it will be a contracted or hired position so that the role can remain neutral and not feel beholden to a specific employer. The expectations for this are to work directly with the technical leader to understand and direct technical efforts for the project, which obviously is easier if they're the same person, to create policies and procedures to streamline technical operations, to direct all assets and services for technical actions. Management of these is often done by an IT group or a program manager, but the decisions are made by this role. To work at all levels of the technical organization to resolve issues and move tasks forward and to maintain metrics for the technical organization to present up to the board or for the technical leader to present up to the board. And then we come to the executive director. The name of this role depends very much on the nature of the organization and its legal entity. It's often described in the project charter as an executive director, a CEO. It could be a general director as one that I've heard. The executive director is at its heart an operational role in that they are responsible for implementing the ideas and the goals of the executive board, so they direct executive actions, and that's why they're included on this list. While there are some very large projects that split this role out into separate roles, for example, Hyperledger has a VP of worldwide alliances and multiple directors of ecosystem, while CNCF has a CTO, a VP of strategic programs for events director along with many other leadership roles. Some smaller projects very often combine these into one. In my current project, Risk 5 International, we have a CEO, a CTO, a chief technical officer and a director of marketing. These roles usually roll up to a single person internally at LF, we refer to that person as an ED, an executive director. Overall, the ED's role is to implement the wishes of the board and that usually breaks down into several primary responsibilities at a host of secondary ones, all depending on resources and project size. The ED very often takes on many roles, especially in smaller projects, and specifically the general manager and chief of staff roles, but often other roles as well. In essence, the ED is the primary gap-filling role as they have to get things done with all the resources at hand. So some responsibilities for this role are to direct or to contribute substantially to board meetings in conjunction with the director or the board chair, to direct and approve finances along with the treasurer, which may be delegated to a VP of finance or a CFO, excuse me, or a similar role, to direct and approve all project activities at the highest level of abstraction, which may be delegated to a general manager, to direct and approve all business development activities. This may be delegated to a VP of business development or a VP of strategic relations, et cetera. To direct and approve all promotional activities, which is often delegated to a director of marketing or advocacy or to a chief marketing officer. To direct and approve all member-relation activities, including maintaining specific relationships with key specific members. This is often partially delegated to program managers or to other roles as well, but it is important for the ED to always maintain a relationship with the community members. To direct and approve all operational activities, the actions are usually delegated to a program manager or an IT person, but the approval comes from the ED. And to direct all personnel hired or contracted by the projects, chief of staff role. This is nearly always held by the ED. It's usually delegated out to other leadership resources in a hierarchy, just like a company does. And of course, the ED is also responsible for anything else that needs to be done, hence the note about gap filling. So let's launch into administrative roles. To administer something is to manage and be responsible for the running of it or to bring it into use or operation. The general manager role incorporates the direction and resourcing all project activities and reporting directly up to the ED who reports to the board. This is the vice president position and in most projects, it's the same person as the ED. In some projects, the ED is even called the general manager. When a project gets to a point where its operations take up enough effort and attention that it prevents an ED from getting high priority things done, it is usually time to bring in a separate director of operations or general manager, essentially to split off that function into a different role. In essence, the marketing director or advocacy director or chief marketing officer is the person responsible for outbound public communication from the project. That is a very sweeping statement intentionally. The role incorporates many expectations, primarily outbound marketing communications, including website content, press releases, public statements, social media accounts, video production. This role handles inbound marketing, including tracking and republishing news items and knowing what's going on with the industry and community. Branding, logos, colors, the trademarks associated with all of those things. Affiliations including regional and industry alliances. Community recognition programs such as the ambassador program, our speakers bureau, community relations, in fact, the community manager role often reports to the director of marketing. Events, which is very often managed by both a separate events manager and board committee, which is usually filled with very motivated stakeholders who like to run booths and speak at conferences. And I'm probably only capturing about half of what this role does. It is gap filling in the sense that if the person as an organization, if the project as an organization is visible in any way, it is likely to be the responsibility of this person. So I think we all know this role, although we sometimes go to the great lengths to avoid them. They can be the nicest folks in the world, and I'm going to say hi to Mike, Scott, and Steve at the Linux Foundation. The legal role is nearly always contracted out to a legal firm, except in the case of a large foundation like the Linux Foundation, that might have its own in-house legal staff for the projects underneath it. The legal counsel for a project is responsible for the project's technical and intellectual property and licensing issues, managing trademarks and other IP that is owned by the project, writing and revising contracts, handling legal disputes, ensuring that legal disputes are minimized, handling code of conduct complaints that are not resolved by any other processes, and doing any other legal activities that need to be done for a project. So if executive roles are the brains of a project, and the administration is the heart, the management roles are the nerves, the muscles, and the skeleton. They are the mechanism by which things get done, very often a primary interface to the rest of the world. Projects don't move without these roles being active. Where administrative roles are strategic, managerial roles are tactical. These roles perform the specific actions or steps you undertake to accomplish the project's strategy. There are many more managerial roles than are listed here, but we'll cover the more visible ones. So, maintainers, these are the technical side. Project maintainers are usually divided up by the major functional technical areas of a project, and they very often correspond to specific code repositories or libraries or programs or whatever other divisions reflect the nature of a project. They are the group chairs that attend TSC meetings to report on how a subproject is doing. More importantly, they are the technical leaders in the trenches, making sure that bugs get fixed, that plans get implemented, that patches get merged, and that community members get answered on mailing lists. Maintainers often work in stakeholder organizations, even in some of the largest projects. When I was at Intel for eight years, we had a team of Linux kernel maintainers whose sole job was to work on the kernel. These are the real heroes of any open source project because they infallibly do what is right for the project, even if it's not best for their particular company. At least not what is immediately best, is those decisions that they make are invariably beneficial to everyone in the long run. The venerable program manager. I found out at Intel, Modivista, and many other companies going back 30 years that program managers are a unique breed. Their charter is to implement and execute programs, but what a program is is rarely defined. So they tend to be the catch-all job description for anyone in a tactical or partly strategic role who gets things done. They end up at the, at every end of the hierarchy, and the job description really just simply should be to fill gaps because that's what we do. This is the role I took on in the OCTO project for many years when my job description actually said community manager. I did that too, but to the benefit or chagrin of thousands of community members. But what I really did was identify priority items that needed to be done and located resources to do them, even if those resources were outside my company or even outside the Linux foundation. I've also filled roles for marketing or advocacy, a term that we attribute to Nithya and Tracy from the OCTO project, as well as business development, finance, events, board secretary, as well as board chair, and even community management sometimes. The one, the role that the OCTO project suited me in 2011 and for some reason still suits is that's what I now do in risk five. Am I crazy? Probably. Marketing managers are the workhorses of messaging. They run campaigns, they manage surveys, create tweets, and essentially function as the voice of the project. Most large projects have a marketing manager or team that is solely responsible for the website, and they often have a dedicated role for social media as well. If you think about it, this makes a lot of sense. The voice of the project has to be knowledgeable and confident as well as totally willing to listen and has to be a voice with empathy that understands what its stakeholders and community members need to hear. Marketing managers typically work hand-in-hand with community managers, as well as, of course, the director of marketing if that role is filled. So unlike the other roles on this list, the board secretary role is usually mandated by a project's charter. This key role could be filled by a number of people within a community and it's not required to be neutral as long as the minutes are written in a neutral and fact-oriented fashion. In small projects, this role is filled either by a board chair or by an admin brought in for the purpose. Larger projects usually have a designated board secretary who's very often a program manager. Sometimes a different role can fill the board secretary role as well. It has to be somebody who understands the specific language and the chartered requirements of the role and also who understands enough about the project to be able to keep legible and interesting minutes. The board secretary role has very specific duties usually called on the charter. They manage the board meetings in terms of calendar entries and official notices. They manage board member access to mailing lists and calendar invitations. They manage board meeting minutes, including usually writing and getting approval from whoever needs to approve it and curating them by keeping them in a very secure place. They manage board votes for organizational items such as approving minutes and any other votes required by the chair. So, community managers, what exactly does a community manager do? That is a very good question that I think a lot of community managers would be hard pressed to answer. However, after 10 years as a community manager I can tell you exactly what they do. They listen. Where the marketing hierarchy is responsible for being the voice of a project, the community manager functions as the ears. More than that, they function as the advocate for the larger community back into the project. Representation is clearly important as so many of the roles we've discussed are representative. The community manager represents the needs of the community to the leadership of a project in a very personal way, ranging from we need more guidance on how to use GitHub to this person offended me and I need help dealing with it to my voice is not being heard at the board level and it needs to be. Community managers also manage Code of Conduct and other social organization complaints. Hopefully after being trained on how to respond to those. There are organizations who specialize in conduct responses and I would highly recommend that if you have a community manager within your project that they take this training. This is an organization that runs it is Otter.technology which is my friend Sage. How a project responds to emotional needs and personal challenges defines its character and the community manager is the role that handles that whether it's a dedicated person a marketing manager's part-time job bullet point for an executive director or the maintainers on the mailing lists. Someone responds to the community or there wouldn't be a community so someone is always filling this role as project leaders you get to choose who handles those responses and that's the community management role. So that's a very brief rundown of the major roles. These slides are available now on the schedule so you can take a closer look. Before I close though I thought it also would be good to take a look to see how these roles are filled in some of the LF's projects. One thing you'll notice in all cases is that each project has access to LF's shared resources the finance, the IT creative services and so on. Each of these services is managed internally and this gives every project an opportunity to take advantage of big company services even if they're just starting out. In addition people in various roles talk and meet very often within LF sharing knowledge and best practices. This cooperation makes LF a very positive and vibrant environment for open source projects at every level. One question we get sometimes is why are some roles only part-time? As we'll see. It makes sense for small projects that only need half of a program manager for example but some have multiple people in part-time roles. Why not just hire one person for the whole thing? This has to do with balancing skills among a team. And as every person comes into these roles with different history and strengths and learning goals for their career we find that this is the best way to organize effort for both the project and the people who fill the roles. So I had the opportunity to work on the LF Energy Project for almost a year and a half as a program manager and a gap filler. This is how LF Energy currently divides up its roles. Its current staff include Executive Director Shuli Goodman, two half-time program managers and a host of other folks who are filling in as advisors or other roles. LF Energy has several projects underneath each with its own technical steering committee. The lead developers serve as TSC chairs and they all meet together as a technical advisory council or TAC where they elect one of their group to be the TAC chair and attend board meetings. The governing board is composed of premier member representatives one director representing all general members and the TAC chair who also votes. The chair and treasurer positions are filled from within the board and they're voted every year. As you can see, members make up the bulk of technical governance for the project while the hands-on executive and administrative work is largely managed by the ED and the program management staff and some services are contracted out. LF Energy is growing very rapidly so there's a ton of work to do and its success is a testament to the organizational skills of everyone on the staff. Note that the ED and PM show up as coverage for multiple roles on this list as well as the dedication of its members and its large community. You can learn more about LF Energy at LFEnergy.org So risk five is a very different organization unlike LF Energy which is part of LF. Risk five is a separate nonprofit entity organized in Switzerland with its own charter and organizing documents. Risk five has had a management services agreement with Lenox foundation since 2018. This is often the best way for incorporated projects like risk five to gain access to the benefits of a foundation while remaining a separate entity. Contracts its own legal counsel outside legal counsel and has its own trademark protection but it still has access to all of LF's array of resources like IT and creative services. Risk five has a larger staff as well with CEO Kalista Redmond in the executive director role as well as a chief technical officer director of marketing to half-time program managers to half-time technical program managers and several contracted resources. In addition, all project activities are duly managed with member resources in the form of committees and chairs. Risk five is really a single project whose deliverable is the risk five instruction set architecture specification but it has dozens of working groups and committees dedicated to this huge and complex effort. The founders are also members of the board and function as advisors into all the technical groups. In short, risk five works very hard as an organization and community to maximize the benefit of both staff and community resources with over 200 organizational members and over 1800 people working in the technical groups. There are a lot of hands working together to create this truly open processor technology and you can learn more about that at riskfive.org or riskv.org. My colleague Daniela Barbosa for helping me sort out the various identified roles in hyperledger as it is a very large foundation style project with a lot of moving parts. Hyperledger has 16 major projects all focused on distributed ledger technologies along with hyperledger labs where community members can initiate projects on their own. It is a very vibrant community with thousands of people and hundreds of member organizations. Some differences with the other projects we've seen TSC chair is drawn from the general community rather than from the members thus they might be a member but that's not a requirement. Governing board roles are filled by members but working group and SIG chairs again are filled by community members. Thus hyperledger is very vigilant about the division between business and technical roles a best practice for open source in general and also strongly encourages the community to participate. Many of the operational administrative and management roles are filled by people working directly for the project including Brian as the executive director, Daniella as the VP worldwide alliances and several other folks. There's a security maven there's a marketing communications manager, community architect and three directors of ecosystem who work directly with the community. Hyperledger is in many ways a model for a large foundation style project. Plus they are all very friendly and their community is very vibrant and welcoming. They're a great example of a well-rounded, well-organized project and you can learn more about them at hyperledger.org Now I don't want you to walk away from this thinking what a load of kumbaya malarky this is no different from a project management seminar. So in very practical tactical terms what can you do today to find the leaders of tomorrow emerging in an open source project and encourage them. And I'll leave you with three tasks that you can do right now after leaving this talk. First understand the roles that your project needs to thrive and how the responsibilities of those roles fit together to create the structure your project depends on. Second, take a hard objective look at the projects you participate in or lead and look specifically for the processes in those projects that recognize or encourage users or chase them away. Are you encouraging competition or cooperation? And how do you think that will play out as some percentage of these participants grow into leaders and fill the roles we've been talking about? Do the people who fill the roles emerge as leaders or are they struggling with workload? Maybe their job is a bad fit. Everybody's just people and often this is not their full-time job so be sure to watch out for each other. Third, share your thoughts on all these roles. Talk with these insights with other leaders in your project. Talk about the tone that is set throughout the project. It is natural to want someone else to take care of these soft skill tasks but it's vitally important to your project that everybody agree on tone as a progenitor of community health and direction. Build the leadership for your project's future by understanding how things are getting done and by whom and by guiding that process intentionally. So I want to thank you very much for your attention and I hope you enjoy the rest of the conference.