5
Governance and Hosting Models
It’s always interesting to speak of governance alongside open source if we recall from Chapter 1, The Whats and Whys of Open Source, the ethos of open source coming from hacker communities that saw problems in the existing methods of producing and using software. You might call them a bit counter-culture, which is a characteristic that stuck with the free and open source software communities for several years of their existence.
But over time, you quickly realize that having models for getting things done is key to long-term success and sustainability. This has been part of our human history for centuries. The Code of Hammurabi in 1755 BC (https://en.wikipedia.org/wiki/Code_of_Hammurabi) focused on creating a standard set of laws and justice for the Babylonians. While mostly known for the principle of “an eye for an eye and tooth for a tooth,” it did accomplish the goal of codifying what was before a loose set of documents and writings in such a way as to set a basis for a society to function. Open source governance aims to provide similar clarity to the community and set a similar basis for projects to work.
This chapter will discuss how governance works in an open source project, looking at a few approaches that consider the different ways to run and organize your project. You will first learn about all the aspects of governance that a project should consider. Then, we will discuss the roles and relationships between maintainers and contributors, how to involve financial support, and how to best document a governance structure. The specific topics to cover will include the following:
- What is open source governance?
- Roles in an open source project
- Documenting your open source project’s governance structure
- Financial support for open source projects
Let’s start with digging into defining governance as we talk about open source projects.
What is open source governance?
Open source governance is simply the processes and policies an open source project needs to have to enable it to function. This can mean many things:
- How can a project accept code?
- How does a project create a release of its code?
- Who determines what code comes into a project and what code doesn’t?
- What does someone need to do to contribute code to a project?
- How are issues handled?
- How are security vulnerabilities addressed and disclosed?
- Who can speak on behalf of the project?
- Who owns the name, artwork, and other assets of the project?
- …and the list goes on.
There are a few approaches to structuring governance in a project, each with different benefits and weaknesses to consider. One thing to know with open source governance is it’s not one-size-fits-all, as there are unique qualities in each community to consider. Let’s take a look at some of the more common options.
“Do-ocracy”
The most basic type of governance is the one that is driven by who does the work – most often called do-ocracy. In the past, this type of governance had been referred to as a meritocracy, but we’ve seen that term go awry, as often merit is tied to forms of discrimination and non-inclusivity. If you dissect the idea of this form of governance, it’s much more aligned with the ethos of those who do the work make the decisions.
Do-ocracy, while being one form of governance, is effectively the basis for most of the forms we will describe in this section of this chapter. In Chapter 1, The Whats and Whys of Open Source, I mentioned Alan Clark calling open source “the ultimate scratch-your-own-itch model.” Open source in general is driven by the motivations of its users and contributors; while many are paid to work on open source, they are paid by those who are motivated to see the given project become successful.
Where a do-ocracy type of governance starts to show its cracks is when there are too many doers. It’s not out of ill intent, but it’s more of a scaling issue. These doers coming to scratch their own itch can have conflicting agendas. Or you might see doers ebb and flow in their commitment over time, allowing some parts of a code base to develop more while others languish. Do-ocracys can often seem like closed clubs from the outside, which can make newcomers joining challenging. At this point is where you will start to see different forms of governance take prominence; one we will look at next is the Benevolent Dictators for Life (BDFL) form of governance.
BDFLs
When projects run into conflict or struggle, we often see them look back to the founder for guidance. This is similar to how start-ups often work, where even if a founder isn’t a CEO, there is the perception that the company is their baby, and there is deference toward them in terms of critical decision-making. Other times, the culture of the project aligns with the vision of its founder from the onset. Both of these cases line up squarely with the BDFL style of governance.
BDFL can be a type of governance that is part of a project from the onset, or it can emerge from the do-acracy form described earlier. We most often see the former: Rasmus Lerdorf with PHP, Linus Torvalds with the Linux kernel, and Guido van Rossum with Python. You could argue Lerdorf and PHP started as a do-acracy, as Lerdorf worked on PHP/FI 2 based on the feedback of users as he released various scripts to the community, and other developers contributed code to the project. While there were numerous developers on the project, the community looked back at Lerdorf for the critical decisions, and he still is widely regarded and respected in the PHP community.
With BDFL, governance is a two-edged sword; many of the successful projects had humble, inclusive, and constructive founder-leaders that helped set a positive tone on how the community should function. Others were divisive, which led to forks in the projects.
Even with the best BDFL, you still have the bottleneck of all decisions flowing through one person. Even Torvalds saw this with the Linux kernel which had several other key maintainers who jump in to spread the load, as there are thousands of lines of code changed each day in the Linux kernel. In many cases, we see projects recognize that there needs to be some sort of formality to leading the direction of projects, which is where we see the next type of open source governance kick in – a technical council.
Technical councils
It’s hard being a founder – just ask anyone who has created a company. It’s also equally hard for a founder to know when it’s time to delegate. Founders typically have a keen eye for how they want their company to run and look. However, at some point, founders do realize they need to bring others in to handle parts of the organization.
In open source projects that I’ve worked with, one of the first things I’ve done is help establish a Technical Steering Committee (TSC). The idea is this group can help lead the project as a group and not rely solely on one person. Here’s the challenge – getting people to step up to be in a leadership role, as many of the technologists I work with simply love the technology and are less interested in the perceived bureaucracy of leadership. So, as a founder-leader needs to bring more people in, it’s often those in the community that want to step up and lead – which is what self-appointing council governance is all about.
You could make the argument that a “technical council” is really a direct evolution of “do-acracy.” After all, both are driven by the people who do the work and want to help lead the work. “Technical councils” are the formalization of the “do-acracy” ethos, put together to build a project that can be sustainable and not have a bottleneck of a single leader. Many of the projects in the Apache Software Foundation, Academy Software Foundation, LF AI and Data Foundation, and LF Energy Foundation are like this. Developers gain interest in a project, and then step up to lead it.
Where the “technical council” type of governance becomes a problem is when the leaders on the council or board start to lose interest, or when there’s a disconnect between leaders and the community. Again, much of this is a natural part of the growing pains that an open source project goes through. When this happens, communities look to become more democratic in their approach, which brings us to the elected type of governance.
Elected
Elected governance is the evolution from a council or board in which those roles are elected rather than self-nominated. This tends to happen most often when competing interests among individuals and companies arise in a project, and a project needs to ensure that decision-making is fair and equitable. To solve that, they hold elections.
Elections can be used for a multitude of reasons. It could be to select leaders themselves, who will serve a term for a certain period. The Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC) does this and has put together a formal election procedure and schedule (see https://github.com/cncf/toc/blob/main/process/election-schedule.md). The idea here is to ensure leaders are rotated regularly, which is good not only for helping bring new ideas and perspectives to a project but also to ensure leaders avoid burnout because they feel they can’t leave a project.
We also see elections used for decision-making within a project community. The Apache Way (https://www.apache.org/theapacheway/index.html) has one of its key tenets as Consensus Decision Making (https://www.apache.org/foundation/how-it-works.html#decision-making). Projects that use the Apache Way (along with many others) use what’s called a lazy consensus approach. This is done by soliciting a vote on an issue of -1, 0, or +1, and if somebody does solicit a -1 vote, they need to either propose an alternative solution or explain in detail why they voted no. What’s good about this is it provides space for constructive dissension and helps a proposal come together that is inclusive of feedback from all parties.
There is another style of governance we see from projects that tend to be more driven by corporate interest, which falls into either single-vendor or foundation-backed governance. Let’s look at both approaches, starting with a single vendor.
Single vendors
Single-vendor governance was most often aligned with the Open Core development model described in Chapter 2, What Makes a Good Open Source Project?. This type of governance is rooted in a single organization creating an open source project, which might be rooted in an existing product the organization has, or could be some internal tool they use that they want to put out as open source.
We see single-vendor governance across three use cases:
- The first is often a pragmatic one; they have some code they want to put out in open source with as little fuss as possible. It’s often code put out there just for the sake of it; if it gets contributions, the organization might just consider that a bonus. There usually isn’t a significant desire to get a large contributor base; it’s most often put out there as something to help users or other individuals that might have a similar use case. These tend to be smaller projects. An example is dispatch, which has been put out by Netflix. Looking at their top contributors that aren’t bots at the time of writing (https://github.com/Netflix/dispatch/graphs/contributors), they’re two Netflix employees, with the next closest contributor only having a small number of commits.
- The second use case is the aforementioned Open Core model, which was described in Chapter 2, What Makes a Good Open Source Project?. Here, the reason for open sourcing is the desire to have a freemium version of a product available, with the intention of users using the project in production and then looking for a commercially supported version. MySQL, Elastic, and MongoDB, among other companies, have used this approach, which, as I talked about previously, has drawn criticism from open source communities.
- The third use case is where a company uses the single-vendor model to seed interest and determine the viability of a project growing. Kubernetes was released by Google in the summer of 2014 (https://cloudplatform.googleblog.com/2014/06/an-update-on-container-support-on-google-cloud-platform.html), and after positive feedback, they used it to launch the CNCF (https://techcrunch.com/2015/07/21/as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation-with-ibm-intel-twitter-and-others). Let’s look more at this style of governance in the next section.
Vendor-neutral foundations
We discussed in Chapter 1, The Whats and Whys of Open Source, how open source foundations came to be vendor-neutral homes for open source projects. It’s often foretold that a successful open source project can often hit a glass ceiling, with many of the following attributes:
- It’s not clear how a project is funded or how it operates, or there is a perception that it primarily benefits a single vendor
- There isn’t a neutral owner of assets, such as the project name, logo, domain names, social accounts, and other assets
- The copyright holder of the project is a single entity, giving them unilateral control to change the license and intellectual property policies without the community’s input
- Vendors leveraging the technology don’t feel they have a space to fairly collaborate, especially if they are competitors
- The legal, fiduciary, and financial aspects of the project are managed by one organization without transparency or given processes
When any or all of these attributes appear, the solution is to look at vendor-neutral foundation governance.
Open source projects looking to go down the vendor-neutral foundation governance path have one of two options. The first is to start their own foundation. Examples here include the Rust Foundation, Python Language Foundation, PHP Foundation, Ruby Central, and GNOME Foundation. Each of these groups tends to be a non-profit entity, is backed either by donations or corporate sponsorship, and usually employs staff to manage and run it. There is a lot of work and cost in setting up a foundation for an open source project, but communities that decide on this usually have very unique needs and considerations.
If projects are less inclined to do the work of forming their own legal entity, existing foundations such as the Apache Software Foundation, Eclipse Foundation, Linux Foundation, or OASIS Open are often natural choices. Foundations such as these have the infrastructure and expertise to set up foundation-backed governance, with lower costs than an open source project trying to do it themselves. Each foundation I mentioned has different niches and strengths that might be of value depending on the needs of the open source project and its community.
With an understanding of the various types of open source governance, let’s look at how the roles within an open source project factor into overall project governance.
Roles in an open source project
As I’ve said repeatedly in this book, every open source project is different. That being said, we generally see a few different classifications of roles in an open source project. Let’s take a look at them now, starting with the user.
Users
Everyone in an open source project starts by using the project. It’s the starting point of the scratch-your-own-itch model of open source; if a project is useful to you, you become invested in it.
As an aside, something we will dig more into in Chapter 6, Making Your Project Feel Welcoming, and to some extent in Chapter 7, Growing Contributors to Maintainers, is why keeping a focus on how users can use the project is so important. It’s also important to recognize that not every user will be a contributor, and that’s okay. However, with lots of users comes not only a higher likelihood of contributors but also a social aspect, which shows potential contributors the value and opportunity of being a contributor.
Nevertheless, having at least some users helping to form the community is the goal, and that comes via contribution. Let’s look at the contributor role.
Contributors
You become a contributor when you do something for the benefit of a project. This can be quite simple. For example, a person puts out a tweet saying, “Just tried X project and it was so good!” It could be someone answering a question on a forum about the project. They might open a bug report, or maybe they have advocated for the project by recommending it to a friend or colleague. These kinds of contributions are often tough to track but are critical to growing a project’s momentum.
Classically, open source projects consider contributors to be those directly providing code to a project. This usually is a high bar for casual users, and more rigorous than just telling someone, “Hey, check out project X!” When you have someone who provides code to a project, this means they not only care about the project but are serious about its usage. In Chapter 2, What Makes a Good Open Source Project?, I talked about my contribution to the repolinter project (https://github.com/todogroup/repolinter).
My motivation for this contribution was that I used this with several of the open source projects I worked with, and found the issue so annoying that I felt compelled to fix it. That’s a high bar; it means that not only was I a user but I also was happy enough as a user to be recommend it in several other projects – and so happy that I saw something not working right and wanted to fix it. If you see contributors like that, be thankful. We will dig more into this in a future chapter.
When you have contributors who hit the high bar of providing a project with code, you can tell they are deeply invested. These are maintainers, so let’s look more at what that means.
Maintainers
Being a maintainer, sometimes referred to as a committer, is one part commitment and another part trust. The commitment comes from that person’s constant presence in the project and interest in driving it forward. This is a person who sees this project as valuable to them, scratching their itch, and helping them with the tasks they might have.
However, the trust aspect is a big part of being a maintainer. Maintainers can change code in a project – that’s a huge amount of trust. You trust a maintainer to know a code base well, including what code is appropriate and what code isn’t. A maintainer can help a contributor refine their code, giving them advice and guidance. And a maintainer knows all the nuances and details of the code base. The maintainers know where the code is good, where it’s okay, and where it needs work. They know how to look out for maintainability problems and address security issues. Big responsibility!
In smaller projects, maintainers are your top role. I work with projects that have only three to four maintainers and several dozen contributors – and that’s perfectly healthy. There is some management involved in keeping these projects sustainable, which we will dig more into in Chapter 7, Growing Contributors to Maintainers. However, for larger projects, we often see either a subset of maintainers or appointed community members that consists of leaders; let’s look at that role now.
Leaders
Leaders in open source communities aren’t dictators (well, except for the aforementioned BDFL, but note we used the term benevolent there ;-)). Yes, leaders in open source projects set the direction, resolve conflicts, and help balance priorities, but more importantly, they serve the community.
Across all of the governance types I outlined earlier in this chapter, leadership in open source means ensuring everyone in the project and community can be successful. This is often referred to as servant leadership, meaning being a leader who provides support, resources, and guidance for others to be successful. Yes, there are decisions to be made, but they aren’t made in a vacuum; they are made with the consideration (and often consultation) of the larger community. After all, the leaders won’t have anything to lead if they make decisions that the community doesn’t like.
With a better sense of the roles involved in an open source project, let’s dig into how to document governance.
Documenting your open source project’s governance structure
As I grow older, I realize the importance of writing things down, mostly because I forget things easily. Yes, I’m that parent who has almost forgotten to pick a kid up from practice, sent them to school without their lunch, or had to run up a form I forgot to sign. That’s part of being human, which is why documenting governance is so important.
It’s also important because it’s critical to understand past decisions in order to make better ones in the future. The whole concept of amendments to the US Constitution is based on that concept. The founding fathers knew that there would be changes in society and evolution in technology in decades to come, so when crafting the US Constitution, they ensured that while the ideals documented would stay intact, future leaders would have the ability to build on them as times changed. Open source projects are similar; the needs of a project with 10 contributors are a lot different from one with 1,000 contributors.
Rust as a project is a good example; while it was an open source project inside of Mozilla Research, it had corporate-backed governance, which made alignment on features and directions easier for the maintainers. However, as it grew to a project with contributors from multiple organizations and formed its own foundation, that simple governance gave way to the need for more structure; thus, the Rust RFC process (https://rust-lang.github.io/rfcs/) was born.
There are a few key attributes to think about when documenting open source governance. Let’s look at the first one – discoverability.
Discoverability
Put simply, make it easy to find the source of governance. Starting with a good README file is usually the best way to get off the ground. A good README file answers the following questions:
- What is the project and what does it do?
- How can you install and use the project?
- If you have issues or questions, where should you go?
- If you want to contribute to the project, how do you do so?
- Where is the project going (also known as a roadmap)?
Resources such as Make a README (https://www.makeareadme.com/) and Awesome README (https://github.com/matiassingers/awesome-readme) are great guides for getting started.
Eventually, a README file can get long, so it’s recommended to break out the content into several files. Typically files you see include the following:
- LICENSE, which details the open source license for the project
- CONTRIBUTING, which helps people know how to contribute code to a project
- RELEASE, letting people know how releases happen
- SUPPORT, where users can go for support
The key part again here is making sure people can find the project’s governance, so sticking to conventional names such as the preceding ones is really important.
Let’s look now at the next key attribute of documenting governance – simplicity.
Simplicity
I sometimes work on projects that feel like they need to make a lot of rules. When you deconstruct the thinking, it usually comes down to fear (which aligns with picking a license, as we chatted about in Chapter 3, Open Source License and IP Management). The feedback I always give is that lots of rules can make it more difficult to get things done, and as we spoke about earlier in this chapter, it’s hard to anticipate every situation.
Some core bits need to be in every open source project’s governance:
- How do you contribute code to the project?
- What is the license for a project?
- How do releases (or the equivalent thereof) happen?
- How are decisions made?
- What are the roles, and how does somebody attain a role?
- Who can you talk to if you have issues or questions?
If an open source project has answers to those points, they tend to be pretty good to go from the start.
I joke with projects sometimes that we don’t get tattoos of the project’s governance on our arms, not just because it would be a really boring tattoo but also because good governance evolves. Let’s talk about that attribute – flexibility.
Flexibility
We’ve talked a lot in this chapter about how open source projects evolve. To do so effectively, they need to be able to easily adjust over time. This is where flexibility in governance comes in.
A good example here is the Zowe project I mentioned earlier. In the early days of the project, their predominant leadership was driven by product managers rather than developers. This was for both pragmatic as well as cultural reasons; pragmatically, code from three companies came together, which was complex, and culturally, product managers in that industry tended to be the primary drivers of software development.
As time went on, a disconnect between the developers on the ground and product management was recognized. Additionally, things such as releases being driven by a single organization were more natural for product management; this becomes a lot harder in open source with multiple organizations contributing. As they assessed the situation, they found that having stronger technical leadership would help them execute better, and thus they transitioned processes to give maintainers more control and leadership, putting the product managers in a supporting and advisory role. This has helped the project become immensely more stable, but also more open to contributions. It was all made possible by including flexibility in the governance model.
One important thing to note about flexibility comes back to the point in the Apache Way on driving consensus. Being flexible means understanding the community and working with them to find a solution. Most importantly, when there is dissension, understand the concerns and try to accommodate them.
One last thing to look at with governance is how to support it financially.
Financial support for open source projects
You may have heard the saying that open source is “free as in speech, not free as in beer.” The free part of open source is the freedom of what you can do with the code, more than the cost of development or ownership being free. There is an economic cost to developing software, open source or proprietary, and that cost has to be borne by someone.
Too often that cost in open source is borne by the maintainer, as they give their time and energy to running an open source project that is used broadly. An xkcd comic (https://xkcd.com/2347/) provides a great illustration of this problem; modern applications stacks have so many dependencies, and a dependency quickly can become a critical one without people realizing how taxing it is on the maintainer.
We will explore more in Chapter 7, Growing Contributors to Maintainers, Chapter 9, Handling Growth, and Chapter 10, Commercialization of Open Source, including the nuances and tensions you see between users and maintainers and why burnout is so prevalent.
There are a few general classifications for open source funding – let’s look at the first one, the tip jar.
Tip jars
The tip jar funding model is quite similar to the person playing an instrument in the street, having their instrument case open and hoping that passers-by drop a few dollars in the case. The mentality that goes into this model is, “Hey, here’s some code I’ve written. Please donate whatever you can if it’s valuable to you.” Some project maintainers will link a PayPal or Venmo account for donations. Others might point to an Amazon Wish List, direct people to add funds to their Starbucks gift card, or maybe ask for donations to a cause that is important to them. Some open source projects that have taken this approach include Transmission (https://transmissionbt.com/donate.html), Conversations (https://github.com/sponsors/iNPUTmice), and Armory (https://armory3d.org/).
The biggest challenge with the tip jar funding model is that it’s not sustainable, meaning that the revenue ebbs and flows. Another major challenge is that if you look at the cost of supporting a user, it often might outweigh any tip given by them. For example, a user opens three issues that collectively require 5 hours of development work. Let’s say optimistically, the user tips the equivalent of USD $5. Assuming an hour of a developer’s work is worth $20 (which is a low estimate), the cost for that user who gave $5 now is $95.
Additionally, the tip jar approach gives users the sense that contributing is putting money in that tip jar, where that user might be able to provide a more beneficial contribution. Expanding on that line of thinking from the example in the previous paragraph, would you as a maintainer rather have $5 or have that person help update the documentation around the three issues reported, which collectively is likely 1 hour of work? The math is pretty clear; while putting money in the tip jar is contributing, there are paths that the user could likely take to contribute that would be more valuable to the maintainer, while at the same time, bringing in the contributor as a participant in the project. This is a concept we will expand more on in Chapter 7, Growing Contributors to Maintainers.
There is another form of the tip jar that is a bit more formal, and we will explore it next – crowdfunding.
Crowdfunding
Crowdfunding is likely a concept many of you are familiar with, as it has become a part of our society through sites such as Kickstarter, Patreon, and GoFundMe. In open source, crowdfunding transitions from the informality of the tip jar to having something a bit more structured.
One key difference with crowdfunding is the ability to use it to raise funding for targeted development. This can go one of two ways; one model is that a maintainer puts out funding requests for a specific issue or feature, and once the required amount of funding comes in, the maintainer pursues development. This is not only a way for the maintainer to help fund themselves to do the work but it also helps that maintainer assess the value of work to the community.
With crowdfunding, you will also see a degree of formality or recognition toward donors, similar to how you might see various levels of donors to a theater or arts program. Blender is a great example of this (https://fund.blender.org/), where multiple tiers offer the donor a badge based on the monthly donation amount, and at higher levels, donors are recognized on the Blender website itself.
One thing about crowdfunding is that there often is a need for a legal organization to accept the donations. Many donors expect some tax benefits depending upon their location, and if the project doesn’t have non-profit status, this could add to the overhead costs of accepting donations. For this reason, we often see projects look at a foundation funding model, which we will explore in a bit. First, let’s look at one alternative path – single-organization funding.
Single-organization funding
If an organization sees an open source project as valuable to their business, they will often look to fund it either through donations, providing funds for developers to travel or the project to participate in events, or hiring all the key developers to be on their staff.
Note that this funding type, as worded, might make it seem like the governance is a single vendor as well, and that is not necessarily the case. Many projects around Apache Hadoop, such as Apache BigTop, Apache Ambari, and Apache Spark, were bootstrapped around single-organization funding even though the foundation governance model was used. Many of these projects with rapid user adoption quickly grew to have multiple vendors providing developer resources, but also had other needs, such as outreach, specialty built infrastructure, or events, funded by a primary organization.
The challenge with single-organization funding is similar to that of single-organization governance; that organization becomes the fulcrum for ensuring the project continues to move forward. For example, when Mozilla laid off many employees that were the core parts of Rust in 2020 (https://blog.mozilla.org/en/mozilla/changing-world-changing-mozilla/), this was seen as a potential blow to that community. Luckily, because of the heavy use of Rust in other organizations, talent was quickly snapped up, but it did cause friction in the community.
From the Mozilla layoffs, a foundation to ensure sustainable funding was born – let’s look at the foundation funding model.
Foundations
The main idea behind the foundation funding model is to have all the funding go into a single, vendor-neutral entity that is overseen by multiple stakeholders and has an independent organization managing the day-to-day finances. For large, critical projects, this has been the trend over the past decade or two; it helps show a natural separation between corporate interests and community interests, and it helps bring together a diverse number of organizations to help fund a project.
There are both funding models for a single project and an umbrella of related projects. How the funding works can be different as well. Let’s look at two examples:
- First is the Python Software Foundation (PSF), which is a US 501(c)(3) non-profit corporation that is an example of a foundation for a single project. The PSF serves three roles for the community; one is to run and manage the annual PyCon event in North America and support other regional Python events globally. Secondly, it manages the legal aspects of the Python project, including licensing and trademark defense. Thirdly, the PSF funds Python development grants.
The PSF is centered around the Python project but also helps manage other related projects, such as the PyPi packaging service. There is some staff to help manage backend operations, as well as help with fundraising. There is also a governing board to provide oversight. Still, neither the board nor the staff gets involved in the technical direction or priorities for the project itself.
- Another great example of an umbrella foundation project is LF Energy Foundation (LFE), a home for open source projects specific to the energy industry and hosted by the Linux Foundation. There are many similarities between the PSF and LFE; both have staff and boards to manage day-to-day work and oversight, and neither the staff nor the board gets involved in the technical direction or priorities of the project itself. Both also fund events, infrastructure, legal aspects, and outreach, as well as providing funding for specific development needs.
- One difference between LFE and the PSF is the legal entity type. While the PSF is a US 501(c)(3) entity, LFE is a US 501(c)(6) entity. The difference in legal entity types in the US comes down to two distinctions; one being that a 501(c)(6) is considered a “trade organization” by the Internal Revenue Service (IRS), which means it is driven by member funding. The second is that contributions made to a 501(c)(6) are not tax-deductible in the US, while donations to a 501(c)(3) entity generally are.
The main differentiator is that with multiple projects hosted, there is a need to have some oversight and coordination between the efforts while at the same time ensuring each hosted project has autonomy. This means that there isn’t an outside group involved in release planning, appointing maintainers, approving code submissions, and setting the direction. This coordination is handled by a Technical Advisory Council (TAC), which sets a life cycle for the project maturity (https://wiki.lfenergy.org/display/HOME/Technical+Project+Lifecycle), as well as a liaison into each project to help support its growth and connect it with other industry initiatives and hosted projects. The TAC has guidelines to help them determine which projects are a fit and which aren’t through their guiding principles (https://wiki.lfenergy.org/display/HOME/LF+Energy+Guiding+Principles).
Summary
When writing this chapter, I came across its opening quote from Sir Winston Churchill – it really is great advice for open source projects.
If there is one piece of advice I could give any open source project, it would be to create the governance you need for today and not create governance for a hypothetical situation in the future. The needs of a project and the culture of its community change over time and adjusting the governance to support those needs ensures buy-in and engagement.
With this chapter, we’ve covered much of the groundwork for building an open source project. As we get into Chapter 6, Making Your Project Feel Welcoming, we will now look at more soft skills and community development to help grow and diversify your community, which is a key part of a successful open source project.