Sustainable Free and Open Source Communities – Documentation

Docs: Introduction

Thu, 29 Nov 2018 14:37:03 -0800

The free and open source community is in a deeper state of introspection than at any time in its history. We are thinking through and having conversations about “sustainable business models” and the rise of “as a service” behemoths in AWS, Google and Microsoft. We are asking ourselves if ethics have a place in our governance and licensing models. We are questioning the fundamental values and ideas of the movement itself.

Since the term “Open Source” was first adopted in 1997, it has become the dominant software development model around the world. Back then, it was a cutting-edge idea - participating in open source was a radical act. Simply participating in it required a philosophical background. Today, you can actively participate in Open Source without any background at all in its philosophy. Open Source is in the water for the new generation of software developers.

Along with the rise in open source development, the number of open source companies has also skyrocketed. Consulting companies, service providers, managed services, and venture-backed startups abound. This influx of capital into the production of open source software fuels our growth. Open Source is eating the world not only because the Bazaar is better for development. It is good business.

This business often happens as direct product revenue–selling open source products to customers. More frequently, it happens when open source software is one component enabling a business to generate revenue. This massive influx of capital, on both sides of the equation, raises interesting questions. Can open source software at this scale exist without businesses funding it? Are we comfortable with how it is used? Where does the community begin and end? Who can take part in the community, how, and why? Who can profit from the software, and how?

35 years have passed since Richard Stallman introduced us to the idea of Free Software. 20 years since the dawn of the Open Source era at Netscape. Why are we building open source software in the first place? What is it good for? Who does it serve? How do we ensure that, no matter what happens, or who participates in our community, that the work we do serves us all? It is time to reassess our fundamental principles.

This is my attempt to start that conversation in earnest. I believe the path forward requires a restatement of our fundamental principles and goals. It leads to a new, intentional, sustainable model for designing our open source communities. It embraces the existence of capital in the system. It reconciles the existence of open source projects with open source products. It is inclusive of everyone who wants to participate.

The result is the creation of the Sustainable Free and Open Source Community (SFOSC) project. There are three parts. The first is the “Principles” - a list of requirements for a sustainable free and open source community. The second is a set of “Community Social Contracts”, the number of which should grow over time. These are explicit social contracts that all participants can agree to and understand. Think of it like Creative Commons, but for community agreements. This document is the last piece - it is the explanation of how I arrived at the beginning of this journey. My hope is that it provides a baseline of knowledge for future collaboration, in the open, as a community. Together, we will evolve the principles, publish many social contracts, and can talk about the trade-offs we make in choosing one contract over the other.

We’ll begin with a statement of my own background and motivations. I want my own biases to be as clear as possible, so they can be challenged as we build on these ideas together. The rest is an explanation of the model and analysis I used to arrive at the “Principles”. I look forward to refining these principles with you, and using them to develop clear social contracts. I’m excited to explore how we can build sustainable communities together.

Docs: Motivations

Thu, 29 Nov 2018 14:37:03 -0800

Why did I create this resource?

For my own part, I started my journey with Free Software in 1994, with a copy of Slackware I installed from floppies. I had been running a Bulletin board system (BBS) for years, and I had become an operating system nerd because I wanted true multi-tasking. I was so proud of running a copy of OS/2 Warp. Slackware changed everything for me - I could see the source code, read the man pages. I could do anything I wanted. I was one of the first people in my circle with dial up internet - so I let my friends call my BBS, enter a passphrase, and then use Linux to dial out via my ISP. It was awesome, and I was all in on Linux.

That led me to a career as a systems administrator. I worked for a series of regional internet service providers, and then for a series of web companies. Throughout, the free software community supported me and mentored me. The Perl community, particularly on Internet Relay Communications (IRC), taught me how to be a programmer. The CFEngine and Puppet communities taught me how to think about automation and scale. No matter what was happening in my career, the software communities I was a part of always supported me. When I struggled, there was always someone who was willing to help, to explain, to show me another path. I don’t know what my life would be like without those communities in it - but I know that I would be less for their absence.

I started an open source configuration management project called Chef a decade ago. It quickly grew beyond my own consulting company into a venture backed startup. Chef–contributors, users, and friends–has grown quite large since then. My business has grown with it. As a venture backed startup, Chef is a success. It is also a success as an open source community - there is a steady stream of people who contribute, who use it in their work, and who help each other with their problems.

Out of all that I’ve done, I’m most proud of the Chef Community and the way it has taken care of all the different people who have joined it. I am sustained by the memories of people who have come up to me and told me how Chef changed their lives. How I changed their lives. They have also changed mine in immeasurable ways. My daughter looks at me differently, because she has seen strangers come up to me and tell me about that impact. I have seen people flourish, grow and change, as people, as engineers. It has been one of the best things I have experienced in my life, and I cherish it.

That community exists because Chef is open source. But not everything we do is open source - we offer proprietary software on top of our open source base. This is what’s termed “open core”. We create a base of open source software, which everyone is free to use, and which the broader community collaborates with us on. We also create proprietary software on top of that base, which we sell to customers for money. “Open core” is the dominant model of using open source in business today.

We add value on top of Chef’s core value proposition, but we never get in the way of that core value proposition. This has an upside - there is zero friction to using Chef to solve your problem. This creates a large “top of funnel” for our business. We have lots of Chef users, who we then try and convince to use our proprietary software as well. The most difficult part of the process is deciding what is the core value, and what is proprietary. When we get it wrong, we either frustrate our community or hamper our ability to monetize.

Here is an example. One recent company, who is in the Fortune 50, sent us an email that went something like this:

Congratulations! Chef is the exclusive configuration management system for us. However, we are not going to enter into a commercial relationship with you, because your business model is bullshit. Love, Massive Company.

I have many problems with that email, but here is the biggest one. That organization is going to use Chef to generate many, many billions of dollars of revenue. We have spent more than a hundred million dollars into the development of Chef. The vast majority of that effort is in open source software. We have grown and nurtured a community I am immensely proud of. Because the tilt of what is free and what is proprietary didn’t convince a Fortune 50 company, they are going to gain all the benefit of that work: for nothing. There is no question that what we have built is valuable. It’s that what we hold back wasn’t enough.

Now, dear reader, I hear you saying to me - “Well, Adam, them’s the breaks! Sounds like your business model is bullshit!“. Which, okay, fine - I accept your premise. The only rational response to it is that I should create more proprietary software. That I should make the open source part of what I do less valuable, so that companies like that have no choice but to pay us.

Another reader: “You still benefit - they will participate in your community!”. Pretty unlikely. If they do, it will be to show up and ask questions. In channels populated with employees Chef pays. With community members dedicated to sustaining the software. This sucks for me, but it sucks worse for those who volunteer their time and effort. How is it a good idea that the community doesn’t get back improvements to the software, directly or indirectly, in return for their efforts? This isn’t helping a single individual over the hump - this is supporting billion dollar revenue streams, with “free” labor, because that’s the way it is.

Here is another true story from Chef: Over the years, many businesses have integrated Chef into their platforms. Many of them created their own proprietary layer on top of Chef, in direct competition with us. An example of such a business was AWS OpsWorks - a hosted management platform built on Chef - which was created by a team in Germany, and then bought by AWS. It’s the nightmare scenario of the people behind the Commons Clause - the fear that AWS would destroy my business, which is funding the software, by launching a competitor.

Lucky for us, that’s not quite what happened. It turns out that, while our stance on what was open was bad in the first example, it’s perfect in this one. Chef continued to evolve the software, in the open, at a rapid pace. OpsWorks was always behind. Some of their features were not supported; some of their workflows worked, others did not. This caused significant demand on AWS to align their service with what we produce. As a result, AWS has now launched Chef’s commercial product as a service. We share in the revenue. The original OpsWorks is no longer pushed strongly as a competitor. The Chef Community–contributors, users, and friends–was the protection we had against the most voracious force the software industry has ever seen.

My entire life in software is possible because I have been a part of incredible communities. Chef is an open source company because I believe in the power of communities. I also took venture capital, and have a responsibility to turn that capital into a thriving business. Looking at it from only that perspective, it is clear what I should do: I should create more proprietary software. I should stop participating in the community, if it means supporting people who don’t pay me.

There’s strong evidence that the more closed companies are, the better they perform. The revenue–and exits–of open source companies is tracked in the Commercial Open Source Software Company Index. These are not exact numbers - these are mainly private companies. Regardless, the trend is clear: The companies with the best business performances are the most closed. They may have large user bases - but they don’t have thriving open source communities. What’s more, in markets where there is competition between open source companies, the most closed company wins.

Clearly, as an open core business, the usefulness of my open source software is in direct tension with my ability to monetize it. The incentive for creating an open source community is that it should be healthy, but not too healthy. In this mindset, the value of my open source software is solely as a funnel to my proprietary software. Nothing more. It breaks my heart.

I want to square my own circle. I want to find a way to no longer be in tension with my community. I want every dollar of revenue I generate to feed and sustain it. I want to generate venture capital sized returns. I want my business to thrive not in spite of its community, but because of its community. I want the predominant way we build open source businesses to be through building thriving communities. Because that’s where the real impact on my life has come from.

I want the incentives to be different. I want the part of the decade of my life that I am most proud of to be the reason my business is successful, not a reason it is not.

Docs: A definition of Sustainable Free and Open Source Communities

Thu, 29 Nov 2018 14:37:03 -0800

What is a sustainable open source community?

If we are to re-align the incentives, we have to start from the top, and that means definitions. When I say “Sustainable Open Source Community”, I mean the following:

A unified body of individuals, scattered throughout a larger society, who work in support of the creation, evolution, use, and extension of free and open source software; while ensuring its longevity through meeting the needs of the present without compromising the ability of the community of the future to meet its own needs.

This definition comes from a combination of my own brain, the Merriam-Webster dictionary definition of community, and the broader understanding of sustainable economic development.

When I say “free and open source software”, I mean it in the terms defined by the Free Software Foundation and the Open Source Initiative’s Open Source Definition. While all Free Software is Open Source software, the inverse is not true. I use Open Source as the short form because it is the super-set of software communities that potentially fit my definition.

My definition precludes “user” communities from being sustainable. An example here is the “Excel” community - while I’m sure one exists, it’s not a community in the sense that I mean it. The community itself isn’t involved in the creation and evolution of the software. At best, they can contribute to its extension. If Microsoft stops producing Excel, what can the community do? They have no mechanism to ensure its longevity. The Excel community is sustainable only so long as it is profitable to Microsoft. It’s a sustainable software business, but not a sustainable community.

This points to the most unique property of a sustainable open source community: longevity. It must be able to produce the software for as long as it is of benefit to the community. As long as we ignore the cost of resources required to run the hardware, the software itself is an infinite resource. We don’t have the same struggle that we would have with, say, sustainable water usage. The software can continue to evolve and be used as long as it is needed.

Participants in a sustainable open source community gain many benefits. They obviously gain the software itself, as a user. They gain the ability to influence the direction of the software. They may gain reputation and visibility. Monetary benefits might flow to them, either through employment or donations. The list encompasses all the benefits of being in a community, plus the software itself.

Our goal is the creation of a community who can sustain the software, and provide benefits to its members, both now and in the future. To do that, the community must create a model where the majority of the value it creates flows to its benefit. Take the example of Chef being Open Core from above. Any value created on the proprietary side of the line is not available to the broader community. While the software itself is an infinite resource, we’ve created a non-infinite downstream pool - we reserved some benefit for a subset of the community, my paying customers. As a result, we created a user community - which, while it may be sustainable as a software business, is not sustainable as a community resource.

Docs: Designing a Sustainable Institution

Thu, 29 Nov 2018 14:37:03 -0800

What makes other communities sustainable?

What makes other communities sustainable? One common thread is that they all have institutions that support and govern them. They could be courts, legislatures, religious hierarchies, fraternal societies; the list goes on. What we don’t find are sustainable communities without institutions. Even anarcho-syndicates form terms of their free association.

Therefore, we need to design an institution that supports and governs the community, which is dedicated to creating the architecture of participation that ensures a thriving community. We need rules for our community’s association. To do that, we can leverage Political Theory.

Political theory is the study of the history, ethics, and legitimacy of institutions and governments. Philosophers like Locke, Rousseau, Kant, Bentham, Mill are examples of political philosophers. Together, they shaped many of the foundations of western society. In particular, two big ideas have dominated the discourse: the social contract and utilitarianism. A social contract is an agreement between people in a community to work together, at the expense of some of their freedoms. “I agree to not steal from others, in exchange for not being stolen from.” Utilitarianism can be summed up as the idea that what is good for the majority is what’s good for society. While the social contract came first, the utilitarian perspective dominated for decades. Let’s dive in to the utilitarian view, then turn to the social contract.

In 1907, Henry Sidgwick summarized the utilitarian view this way:

Society is rightly ordered, and therefore just, when its major institutions are arranged to achieve the greatest net balance of satisfaction summed over all the individuals belonging to it

The main idea is this: when there is more total satisfaction (“the good”) in the society, things are just. This can (will?) happen at the expense of the minority, as long as we have more aggregate goodness in the system. The problem with a utilitarian view is that it is concerned with the total amount of goodness in a society: it doesn’t care about ensuring any kind of distribution of the good. It can be weighted strongly toward the majority, even a small segment of the majority. A strong majority controlling everything might create sustainable software (like our Excel example.) It is unlikely to create a sustainable community for long - it will continue to accumulate the good for itself, at the expense of others. Political theorists have spent a huge amount of effort trying to soften this blow, to no real avail.

In 1973, a political philosopher named John Rawls dropped a bomb on the utilitarian viewpoint. He focused on the idea of the social contract as the basis for a just society with his “Theory of Justice”. Here is Rawls explaining his point of view:

Justice is the first virtue of social institutions, as truth is of systems of thought. A theory however elegant and economical must be rejected or revised if it is untrue; likewise laws and institutions no matter how efficient and well-arranged must be reformed or abolished if they are unjust. Each person possesses an inviolability founded on justice that even the welfare of society as a whole cannot override. For this reason justice denies the loss of freedom for some is made right by a greater good shared by others. It does not allow that the sacrifices on a few are outweighed by the larger sum of advantages enjoyed by the many.

Rawls then sets out to define the principles of justice itself. How would we know that the rules that govern our society are, in fact, just? He comes up with two principles, which he refined many times over the course of his life. Here is one statement from a speech he gave in 1996, referenced in the Oxford Handbook of Political Theory:

Each person has an equal claim to a fully adequate scheme of equal and basic liberties, which scheme is compatible with the same scheme for all; and in this scheme the equal political liberties, and only those liberties, are to be guaranteed their fair value.
Social and economic inequalities are to satisfy two conditions: first, they are to be attached to positions and offices open to all under conditions of fair equality of opportunity, and second, they are to the greatest advantage of the least advantaged members of society.

The first principle is called the “equal liberty principle”. The second is divided up into two parts: “fair equality of opportunity” and “the difference principle”. He goes on to state we are not allowed to trade the first principle for the second. We cannot trade our basic liberties for any benefit, regardless of who it benefits. Further, fair equality of opportunity comes before the difference principle. We cannot give an advantage to one person at the cost of another person’s fair access to opportunity. Finally: when we do have inequalities, they must be to the benefit of those with the least.

Rawls then defined the “social and economic” benefits in terms of the “primary social goods”. He defines these as “things we might want, whatsoever else we might want”. For Rawls, that meant things like freedom of movement, freedom of speech, and free choice of occupation. These are the things that we won’t ever trade. After that, we want all kinds of things, including: access, prestige, and money. We accept inequalities in those things only if they meet the conditions of fair equality of opportunity and the difference principle. They must be equally available to all, and benefit the least advantaged.

He justifies these principles through designing a game using a device he called “the original position”, but more commonly known as “the veil of ignorance”. Imagine we were brought together to design a society from scratch. We are not allowed to know in advance what position we will occupy. We are going to agree to some rules, then roll the dice to see where we will wind up. Will we be in the middle? The top? The bottom?

From this position, Rawls postulates that reasonable people would adopt his rules. We would need some basic liberty to exist, because we would not accept a situation where we wind up a slave. There is some unacceptable floor. We would require the ability to strengthen our social position, so we could improve our lot. Finally, we would mandate that those with the most cannot hoard their resources. Otherwise, our ability to improve will be limited by those with the most. From this position we can see if our system would be just: regardless of where you start, the game is fair. (Rawls theory is often summarized as “Justice as Fairness” for this reason.)

Rawls work has dominated political theory since he stated it. It forms the basis for almost all the study that has come after it, and depending on your perspective, has some holes. In most cases, these stem from the complexity inherent in talking about society on the scale of the human condition. If we scope things down to a single sustainable open source community, we can avoid many of those issues. We can use Rawls’ theory to test whether an existing open source community is just, and thus sustainable. From there, we can collect a set of principles that all sustainable free and open source communities should abide by.

Docs: Setting up Rawls' Game

Thu, 29 Nov 2018 14:37:03 -0800

To begin, we have to decide what the primary goods are. What is the thing we want, whatsoever else we might want. We can take for granted Rawls list (freedom of expression, etc), since we are scoping things down to our sustainable open source community. In its place, a reasonable statement of the primary good we want is:

We want the software to exist, to solve our problem, to continue to improve, and to be available for our use.

Since our primary good is software, it has the unique property of being infinite in amount. If we want more of it, we can simply… create more of it. This definition ensures we will not trade away our ability to be sustainable.

Now we need to apply the equal liberty principle. What are the rights we won’t trade?

It turns out that the Four Freedoms set forth by Richard Stallman (RMS) are a perfect fit here. (I suspect not by accident - I put the odds that RMS didn’t read Rawls in 1983 at slim to none.) They are:

The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

By adopting the four freedoms as our foundational rights, we guarantee our community’s basic liberty. Regardless of our position in the community, we will always have access to our primary good. Anything less than the four freedoms and we could easily be in a position where we are locked out of the community. Where our basic desire goes unfulfilled. By agreeing to never trade away our four freedoms, we fulfill the equal liberty principle.

This implies that, to be sustainable open source community:

The software must be released under a Free and Open Source license.

This could be a ‘copyleft’ license like the GNU General Public License (GPL), or a ‘non-copyleft’ license such as the Apache License. The specific license doesn’t matter - only that it upholds the four freedoms.

This is, of course, not quite enough. We want more than just basic liberty in our lives - the “whatsoever else we might want” part of Rawls conception of the good. We want prestige, we want influence, we want money, we want friendship - the list is long. Simply having the software isn’t worth much if we can’t ensure a long life together as a community. It may give us liberty, but it won’t give us fraternity.

Once we start injecting the other things we want into our community, we are going to cause inequality. We need to ensure that those inequalities meet fair equality of opportunity and the difference principle. To do that, we need to have a better understanding of what the positions are we might occupy in our community. What are the different outcomes of the dice roll that determines our fate?

Founders: the original authors of the software. They begin with 100% of the goods in our community. (If it wasn’t for their initial decision to create a community in the first place, there would be no community.)
Developers: people with the technical ability and desire to improve the software; for their own benefit, the benefit of their employer, the desire to be active in the community or a combination of these.
Contributors: those who engage in the work of making the software better. This does not necessarily mean writing code: they might file bug reports, compile release notes, write documentation, answer questions, etc.
Champions: people who promote the benefits of the software and benefit by gaining visibility and authority.
Non-Commercial Users: folks who use the software to solve their own problems. Distinct in that they are not solving the problem of how to generate wealth with the software.
Commercial Users: users of the software who are solving problems related to generating wealth. Distinct in that they are not generating wealth from the software directly.
Software Businesses: entities that sell a build of the software, and provide support for its use.
As-A-Service Businesses: distinct from software businesses, in that they provide the software as a service, over a network.
Managed Service Businesses: similar to As-A-Service Businesses, but provide the software as a service at a location of the consumer’s choice. Manage the lifecycle of the software on behalf of the consumer.
Consulting Businesses: sell implementation and strategic consulting around the software.
Venture Capitalists: people that provide funding of businesses in return for a stake in the business. Have the express desire that the business grows significantly in value.

This conception of community is an expansive one - it includes not only software developers, but anyone who has a stake in our community. How can we exclude the contributors who don’t write software? The venture capitalists who bring massive amounts of money to the table? All these are different aspects of the work involved in supporting the creation, evolution, use and extension of the software. We have to include them all, and as we discover new ones, include them as well. If we do not, we can’t be sure we’re evaluating our rules against a realistic field.

Docs: Governance and Behavior

Thu, 29 Nov 2018 14:37:03 -0800

How is a community or project governed?

Lets start by evaluating how to provide fair equality of opportunity for the direction of the project. I see three common models:

Dictatorships, such as Linux, Python (before the resignation of Guido van Rossum and the adoption of a steering council model), and Chef.
Self organizing with loose consensus, as best seen in the Rust community.
Democracies, represented by the Apache Foundation, The Debian Project, and OpenStack.

How does each stack up to Rawls’ principles?

The dictatorship model has an individual, often the founder, holding 100% of the authority over the projects direction. Usually they then delegate responsibility to trusted lieutenants, who then further delegate to individuals or teams. Those teams often feel democratic at the bottom - some amount of public conversation and loose consensus is found at the edges of the project. Yet the power in these models is fixed: the leader holds ultimate power. The community puts its faith in the judgement of the leader.

The advantage of this model is often perceived to be streamlined decision making, and a focusing on the founders’ moral authority over their work as the most legitimate way to decide the projects direction. Taken through Rawls lense, though, it is hard to advocate for this type of leadership. While it may be efficient at breaking ties, or resolving dispute, it clearly denies the ability for any community member, other than the founder or their hand picked successor, to advance to the level of ultimate leadership in the community. All participation or advancement is at the personal whim of the founder. They may do a good job of ensuring that both fair equality of opportunity and the difference principle are applied in their personal decision making - but since the position in which their authority is vested cannot be held by any member of the community, it ultimately fails to satisfy fair equality of opportunity - which means they are un-just at their foundation.

Similar problems plague the loose consensus decision making of the Rust community - a community that I would say is a model for pleasant and meaningful open source. Rust consists of several teams, with ultimate authority resting in the “core team”. This group is responsible for creating “sub-teams” that focus on particular areas, each led by a member of the core. The sub-teams themselves have the responsibility for driving their own membership guidelines, and for making decisions based on Rust’s own core community value of consensus. A significant amount of effort has gone in to this structure, and in practice, it’s clearly working well. However - the issue here is that, ultimately, if the core team itself should fail to represent the will of the Rust community, there would be no recourse. Other than participation, and a relatively opaque conception of what behavior merits sub-team (and ultimately, core team) membership, there are no guidelines at all. As an institution designed for longevity, the lack of clarity on how members of the core team are decided and removed means that it’s in a space of uncertainty: as it is currently operating, you could easily argue it fits all of Rawls tests. But it could clearly turn to a model where the core team decides to behave in a way the rest of the community disagrees with, or to its own benefit. Looking at Rust is interesting for our process, because it clearly is generating net-positive results, both for the software itself and the community around it - and yet, it’s impossible to say it will remain that way. While producing world-class results, Rust fails to meet the bar for equal opportunity of access or the difference principle - in its attempt to allow the teams to self organize, they fail to ensure the Rust community can remain as egalitarian as it is today. It’s lack of guidelines are its trouble.

Finally, we can look to the democratic model. This is best represented by the Apache Software Foundation’s governance model, the Debian Project and the OpenStack Foundation.

Apache publishes an organizational chart that is instructive here. They split the organizations governance into two parts - the corporate governance of the foundation itself, and the project governance for each Apache software project. The Apache members, all of whom are individuals with a single vote, elect a board of directors, who then appoint a president and corporate officers. For each project, the board creates and updates Project Management Committees (PMCs). The Chair of each PMC is appointed by the board. The PMC Chair then has the power to establish the rules for the day to day functions of their project. You can see the similarity to the Rust model - at the level of any individual Apache project, there is broad latitude for the day to day functioning of the project to be decided by the project itself, while still being morally beholden to the Apache Way (which is, itself, not clearly defined). Fundamental to the Apache model is that members get to vote in the board, which then has a responsibility to oversee strong executive leaders with broad latitude to do as they see fit for the projects they manage. The result is that it strikes a balance between the efficiencies of a pure dictatorship (through the consistent use of powerful executives with broad personal authority) and the loose consensus of Rust.

A flaw in the Apache model is that, in order to be eligible to vote, you must first become a Member, and the terms fail the difference principle. Membership is invitation only - new members are proposed and voted on by the existing membership. Here the foundation relies on the idea of meritocracy, “meaning that contributions and skills are the factors used to judge worthiness”. The difficulty, of course, lies in deciding what behavior is, in fact, worthy of merit. Apache makes no such attempt at defining merit - but it is implicit that one aspect of merit is being able to directly contribute code to an Apache project. The side effect is that, with the Apache model, we run the risk of excluding members of the community whose contributions don’t match our collective idea of merit, and it is highly likely this will be perpetuated - why would the existing membership, all of whom share the same implicit idea of what is worthy of merit, ever expand that point of view? Again we find a spot where, in practice, Apache is largely upholding the idea of equal opportunity of access; but it may very well be failing to uphold the difference principle, since membership in the community (and therefore access) may not include all members of the community.

The Debian Project is a community dedicated to the creation of a free software operating system, and it’s another example of democracy in open source development. It has two foundational documents: The Debian Social Contract, which defines their principles, and contains the Debian Free Software Guidelines, which defines what software is considered for distribution; and The Debian Constitution, which describes the organizational and decision making structure for the project. In broad terms, Debian Developers vote on General Resolutions, hold Elections, may override any decision made by any elected official, and amend their constitution (on a 3:1 majority). The Project Leader is elected by the Developers, and has broad latitude to delegate their substantial authority as they see fit. One of the Project Leaders powers is the appointment of members to the Technical Committee, which has the authority to overrule decisions of individual developers, decide on technical matters, and set technical policy.

Originally, Debian Developers were always considered as people who developed or packaged software for Debian. However, by general resolution in 2010, the guidelines were updated, and non-packaging contributors were welcomed in to the fold. To become a member, and therefore to have a vote, you need to: be contributing to Debian; fill out an Application; have an existing Debian Developer advocate for you via an email describing what you have done for the project; have your identity verified; have your understanding of debian philosophy and procedures validated; and have examples of your work available. Assuming all goes well, you are then considered a voting member of the project.

Debian clearly meets Rawls’ criteria, by resolving the issue with the Apache model - the institution that governs the community has broadly achievable membership, which then confers the ability to gain access to positions of power within the community, including the ultimate authority conveyed by the project, that of the Project Leader. Votes by members all have equal weight, and the constitution contains procedures for voting, certifying the vote, and more. Like every model we have seen so far, it invests authority to a strong executive, who then has wide latitude for conveying their authority to others within the project, and relies strongly on consensus before requiring dispute resolution to happen via a formal method.

The OpenStack Foundation is interesting because it functions as a democracy, but with different levels of voting participation. It is governed by bylaws, which define how the project and the non profit foundation that administers it will function. Technical decision making is done through an elected technical committee, which has broad leverage over the day to day decision making of the project. The foundation itself is overseen by a board whose membership includes indviduals and two levels of corporate sponsorship (“gold” and “platinum”). The corporate membership types are fixed in the bylaws of the foundation, and both have capital and contribution requirements. Individual membership is made through an application process to the project Secretary, with simple requirements (name, affiliation, statement of interest, and contact information.)

The board is elected as follows: platinum members are allowed to appoint a single member of the Board, and their number sets the “director limit” (currently at 8). Gold members then vote amongst themselves to determine who is allowed to select the gold member seats on the board, filling 8 seats. Then individual members are allowed to vote, electing 8 individual members to the board. This board has all the rights that are not otherwise delegated to a committee (for example, they don’t have the right to make technical decisions for the project, but they do direct funds.)

The technical committee is selected by a vote of the “Active Technical Contributors” (ATC). These are determined as a contribution approved to any of the official OpenStack Projects, or if they are not a technical contributor, they can apply to the chair of the technical committee, who then brings it to a vote of the committee. The technical committee has broad latitude for its own governance - it has published a significant amount of rules over the years. Additionally, the project recognizes the role of Project Team Lead (PTL), which is elected from a similar membership process, for each project under the OpenStack umbrella, and has broad technical latitude.

OpenStack takes steps to mitigate any individual company gaining control of the project (through their rules around Affiliation,) ensures that any modification to the bylaws require a ²⁄₃ vote (and modifications relating to membership classes requires a vote by those membership classes), and various times when votes are required by the larger body of members. Through the existence of the PTLs and the Technical Committee, OpenStack creates an internal model that is not that different from the Apache model (separate technical decision making from the foundation itself, strong individual leaders with broad authority over their project.)

Most interesting for our purposes is the existence of multiple levels of voting on the OpenStack board itself, according to the varying membership levels, and the admission of corporate entities who then nominate representatives. Do the Platinum and Gold memberships violate the fair equality of opportunity or the difference principle?

In both Platinum and Gold cases, there are significant revenue and participation requirements: $500,000 a year (with a 3 year commitment), and gold is 0.025% of revenue with a minimum of $50,000 and a maximum of $200,000 per year. Essentially, the foundation takes in capital in return for the ability to have influence over the issuance of the OpenStack Trademarks, influence on decision making for the foundation’s budget, and the election of officers.

Since all work done by the OpenStack Core must be licensed as Apache 2.0, we know that taking the capital doesn’t violate our basic liberties - we haven’t traded the four freedoms. While we have traded money for influence, we have limited the scope, through ensuring specific changes to the bylaws require larger votes of the membership. Their presence on the board gives them influence in some positions of authority (such as hiring officers of the foundation, who draw salaries). The issue is that the platinum and gold members have enough seats on the board that they can vote as a block against the interests of individual members - they have a ²⁄₃ majority of the board.

I believe this means that the OpenStack Board fails to meet both the equal opportunity of access and the difference principle. The failure of equal opportunity of access is caused by the skew in the voting requirements, which the board uses both to provide positions of authority within the foundation, and to appoint new members to the board directly (existing Platinum members have more weight than Gold or Individual, respectively). Clearly, the bar to achieving Platinum membership is not equally available, and the influence purchased is significant.

While this is enough to disqualify the model, it is also clear that the board’s structure fails to address the difference principle. Imagine you are an individual contributor who believes the status quo structure of OpenStack to be unjust as I have just described it, and who then decides to lobby for a change in the by-laws. By design, the rules do not favor you (the member with the least) - the community favors the other classes of member, ensuring that if their interests are in conflict with yours, they will never be seriously threatened. We’ve curtailed the rights of the individual members to increase the rights of the corporations. Put on the veil of ignorance, and imagine the difference between coming out the other side a Platinum Member versus an Individual Member.

Given this analysis, what are the attributes of a sustainable open source community’s governance model?

Rules for membership must be published and adhered to.
Membership must be open to all classes of contributor to the community. It must not be limited to technical contribution, nor to any kind of external status.
Membership must have requirements for validation of identity, and review of contribution to the community (to avoid stacking the membership roles). Any impediment to membership must be low enough that a person with the least advantage could achieve it.
Voting processes must be put in place, which give each member an equal vote.
All positions of authority in the project must be, directly or indirectly, the result of a vote.

Beyond this, we can draw a couple of conclusions that, while not strictly necessary for the system to be just, seem to be common across the vast majority of successful technical communities:

The membership should vote to elect a strong executive (either an individual or a committee), with broad latitude to structure the technical work of the project as they see fit.
An elected board should exist, to manage disputes and issues with the executive, and to manage any community resources.

In addition to governance models, the other practical obstacle to participation is the interpersonal behavior of the community itself. Imagine that, while we adopt all of the rules above, we require that members acquiesce to existing members’ abusive language, harassment, racism, etc. In this case, we would fail to provide equal opportunity of access - you’re allowed to join, but only if you’re willing to suffer our withering attacks. So we can add one more attribute to a sustainable open source community:

It must have a strong code of conduct, with clear, fair enforcement mechanisms.

Docs: Contribution and Distribution

Thu, 29 Nov 2018 14:37:03 -0800

How is work contributed, and distributed?

Having established the rules for governance and behavior for the community at large, we can turn to the terms under which work is contributed to the community, and how it is distributed to others. To cover this, we need to introduce the different levers at our disposal: copyrights, trademarks, patents, terms of distribution (end user license agreements, or EULAs), and terms of service.

(As an aside: these terms are not defined or enforced in the same way around the globe. Rather than have an intensive debate about the particulars of any given nation’s stance, I’ve stuck to the terms as widely understood in the United States. While other nations might behave differently, for the terms of discussing what the attributes of a sustainable open source community are, I think they serve just fine.)

Copyright is the idea that, as the creator of something, you have the right to decide how it will (or won’t) be used. Trademark is the idea that, if we both create similar things, I can’t pretend that my thing is your thing (if we both make Cola, I can’t say my Cola is Coca-Cola; because only Coca-Cola can be Coca-Cola). Patents are how we say that we have a special way of creating our goods (while we both create cola, I have a special way of making cola, and only I am allowed to make cola that way, unless I give you permission). Distribution terms mean that, while we might both make identical items, this particular set of things comes from me, and has some terms attached that I desire. Terms of Service allow you to set terms on how someone uses your goods as a service (such as when you use a website, or use a managed service.) When you are allowed to take another persons work, and combine it to create your own work, you create what is known as a “derivative work”.

Starting with the clearest item, in Rawls terms, first: Patents. Given the requirements of meeting the four freedoms as a guarantee of our basic liberty, it’s clear that we need to have the right to both use a patent directly, and to create a derivative work that contains a patent. Otherwise, our community might not be able to exist, or certain contributors could use their proprietary patented method to exclude others in the community. So we can add another attribute:

Any patents included in the software must be granted under the terms of the open source license.

In the copyright model, each individual contributor retains their copyright over the work they have created. Let’s say you create a piece of software called “Kitten”, and you decide to publish its source code under the terms of the Apache License 2.0, and create a binary distribution of the software under the same terms. Your work is useful, and someone else decides to modify the program for their own benefit. They now have a new, derivative work of Kitten, whose copyright consists of your work and theirs. We can now consider your version as “upstream”, and their version as “downstream”. They decide that they want to contribute their modifications to the program back to you, so that you (and others) can benefit. They would then license their work back to you, under the same terms (Apache License 2.0). Assuming you accept it into your distribution of Kitten, the resulting release of Kitten is covered by copyrights owned by both you and them.

A corner case exists here we must address - you can assign your copyright to others. Assume in the story above, the upstream might decide that, in order to incorporate the downstream changes back into its distribution, the downstream needs to assign the copyright to the upstream. This grants the upstream broad latitude to do whatever it likes with the combined work - up to, and including, re-licensing it under different terms. This is the primary lever of the “dual licensing” model - companies require copyright assignment, then sell the software under multiple sets of terms: one for an open source version, and another for commercial use or integration. These schemes uphold our basic liberty, assuming one of the licenses it is released under is a free and open source license (in a pinch, we could always fork the software). However, they do pose issues with fair equality of opportunity: since the ultimate copyright holder is the only one who can re-license the software, they reserve for themselves a level of status that is unattainable by any other persona in the community.

The other use case for copyright assignment is giving the software to a foundation, such as the Free Software Foundation. In this case, the intent is to ensure a single entity has the ability to enforce the copyright license. There remains some debate about whether this is necessary - but, regardless, these organizations make commitments about the use of the copyright (they will use it only for enforcement, not to relicense the software.) This gives us two attributes about copyrights:

All contributors must retain their copyright, unless the software is being managed by a foundation for the purposes of license enforcement
All contributors intending to have their work incorporated into a distribution must contribute their work under the same terms as the software license they received it under.

Let’s take a different tack - assume in the story above, the downstream decided to continue forward, but not to contribute back. This would be a “fork” - a new distribution, with a shared origin, but now divergent from the upstream. How the community feels about this is one of the primary drivers of license choice - the copyleft licenses put the requirement for downstream works as a viral component of their liberty: you can take the work, you can create a derivative, but you must ensure the same freedoms for your derivative as those you enjoyed. The non-copyleft licenses vary widely in what they cover, but the commonality is that they put no such requirement on the recipient: while you may decide to contribute, or you may decide to publish your work under similar terms, you don’t have to. The door is open to creating derivative works that do not share the freedoms of the upstream.

Docs: Business Models

Thu, 06 Dec 2018 14:37:03 -0800

Business models for sustainable open source communities

From the perspective of creating sustainable open source communities, clearly it is better when we have more of the software in the open, not less, and the finger points strongly at using not only copyleft licenses, but the strongest possible variation that makes sense for the type of software we are building. Where things get more complex is when we start to creep Rawls back in: we want the primary good to increase, but we also want other things. Money, for example - both directly in our own pockets, but also as a source of growth for the software itself. While having software under a strong copyleft might be appealing for some cases, clearly for other community use cases it closes the door. When we start to look at these business personas, the question becomes: how can we monetize the software in a just, sustainable way? There are eight common models: the free software island, loose open core, tight open core, dual licensing, as a service, donations, support only and the free software product model. How does each fare?

Free Software Island

The best example of the free software island model are The Apache Projects. The Apache Software Foundation exists to provide a framework for creating free software, ensuring that it remains focused on the software itself, and that it remains free from direct commercialization. As a consequence, it holds tightly to the trademarks for the Apache Projects, and does not allow them to be used for commercial purposes. By creating a moat between the free software and the commercial entities who might build businesses on top of it, the Foundation can ensure that, on the island, the project is free to make the right decisions for the software itself. This distinction is core to the model - Apache doesn’t build products (those are what companies build), they build projects. This makes Apache the upstream for many companies - a great example being Datastax and Apache Cassandra. While Cassandra is the core of Datastax, Datastax itself is increasingly proprietary software (Datastax Enterprise, or DSE) - it looks at the value provided by Cassandra, and builds value on top of it. In their own words:

DSE goes beyond Apache Cassandra, delivering twice the performance and half the latency of open source Cassandra, as well as simplified operations management.

The combination of Apache Cassandra being under the permissive Apache 2.0 license means that everyone is free to use the software, and to incorporate it into their derivative works, regardless of whether those works are themselves free. Anyone can take Apache Cassandra, start a business, and build on top of it. The Apache Cassandra community likely gets some benefit if they are successful, since some of the work required for building Datastax is best contained within the upstream Cassandra itself. However, in order to distinguish themselves from the purely free (as in beer) Cassandra, Datastax diverts some of their value into proprietary software - software that clearly isn’t being used to further our sustainable open source community anymore. This means that the model passes all of Rawls tests of fairness from the perspective of the island itself: it doesn’t constrain our basic liberty, it is equally applied to everyone, and whatever inequality might exist bends toward those with the least.

It has an unfortunate side effect, though: by segregating the community responsibility on the island, it creates a dynamic that the downstream companies will be best served by putting maximum effort into proprietary extensions, and cooperating only where strictly necessary. If a downstream company tried to ensure that all the work they did went to further sustaining our open source community, they would quickly be overtaken by their competitors, who would gain all the benefit of their engagement in the community core, plus the benefit of their proprietary focus. An example is the Apache Hadoop ecosystem, which generated two public companies, Cloudera and Hortonworks - who merged as public companies at a ⁶⁰⁄₄₀ level. Cloudera was the more proprietary of the two, and took a significantly larger share of the market value, while clearly contributing less to the core of Hadoop.

A free software island with different dynamics is Linux. Linux uses the GNU Public License version 2 as the license for the software. The trademark is held by Linus Torvalds, the creator of Linux, and administered on his behalf by The Linux Foundation. Linux itself is an operating system kernel, not the entire operating system - and the dynamic this creates is that many Linux Distributions exist, ranging from completely free and open source (Debian GNU/Linux) to fully proprietary (Red Hat Enterprise Linux). In all these cases, the license of the Linux Kernel ensures that any downstream derivative of the kernel will have its source made available. In practice, this means that the vast bulk of work on the Linux kernel, and of monetization around the Linux kernel, benefits the kernel community. There is no possibility of a downstream proprietary Linux kernel. For purposes of evaluating the model as one of sustainable open source monetization, the kernel model drives any downstream monetization effort to collaboration on the kernel itself. As a case study in monetization, it’s a great example of how license choice and type of software make the difference in deciding if this model is a good fit. If Linux had ever tried to expand beyond the kernel itself, the model falls apart. By drawing the free software island around an indispensable, but insufficient, component of the overall system, ensuring that use of that component will always result in more contribution (or possible contribution) to the component through licensing, and encouraging the growth of businesses around the component, the kernel community is a deeply sustainable one (at least, from this point of view; it fails many of our earlier tests.)

Loose Open Core

Switching gears, Loose Open Core means that you have a “core” of the software which is open source, and you build products around (but not directly a part of) the core. Chef Software and Puppet Labs are two examples of loose open core companies. They both produce a large body of open source automation software, released under the Apache 2.0 license. They add products like Puppet Enterprise, or Chef Automate, which provide features that would be useful for their target market (the large enterprise.) In this model, the business tries to draw a line that says “you can use and be successful with our software, but if you want this extra functionality around it, you need to pay us”. This model is trying to balance having thriving communities, both of users and of customers, with the need to provide proprietary differentiation across the product portfolio. The struggle here is usually that, for this model to work, you need to have a project that generates a high volume of users - which means the core product contains everything a user would need to be successful with the software’s primary use case. For Chef and Puppet, that primary use case is at scale configuration management - in both cases, you can run massive organizations, and solve huge configuration management problems, without needing to purchase anything from either Chef Software or Puppet Labs. In our examples above, both companies have taken significant venture capital, and are the upstream of the project - there is no separation between Chef and Chef Software, or Puppet and Puppet Labs.

Looking at things from our sustainable open source community perspective, things get murky. Clearly, the software that is open source fulfills the basic liberty; but in exchange for that software’s continued development, we trade some functionality (the enterprise features we build around the core) away from that basic liberty - we make it proprietary. The lines of our community are blurry: where does the Chef Community start, and Chef Software begin, when they are so intermingled? If we draw a circle around the software, and say the community exists only there, we get the same results to the free software island model. If we extend it out to our full, expansive definition of community, then it’s plain it no longer fits, as we have traded basic liberty for more of the software.

Tight Open Core

This problem becomes most clear when we look at tight open core. Take, for example, Elastic and Elasticsearch. Elasticsearch is open source software, developed primarily by Elastic. Rather than put software around Elasticsearch and monetize there, Elastic puts features needed by their target market in to proprietary plugins. The results are that features such as authentication are held back from the open source offering, in order to ensure an easier path to monetization. This model can be highly effective (Elastic has a very tidy business!), but it clearly is not one that creates a sustainable open source community: what would the response be if, in order to have the software work for your purposes, you desired authentication, and proposed adding that capability in to core? This is another obvious moment: we’ve traded away our basic liberty for software that is only useful for a fraction of our purpose.

Dual Licensing

The open core models generally are paired with a non-copyleft license, since to do otherwise would compromise your ability to produce derivative works without copyright assignment. A particularly closed twist on this model is the one employed by MongoDB: they require contributors to assign the rights to their copyright to MongoDB (the contributor also retains their rights, a change to standard copyright assignment). This allows MongoDB to create a tight open core model where they produce an open source version of MongoDB under the Affero GPL, and retain the rights to create proprietary versions, or to sell a hosted version without being forced to release it into open source MongoDB. This is the dual licensing model at it’s finest: you release the software under an aggressive copyleft, but retain the rights to remove those restrictions for yourself - the loophole that allows the company, and only the company, the ability to monetize the software effectively. It fails our test on every measure, since MongoDB holds rights for itself that the community can never match, regardless of where we draw the lines for the community around the open source software.

As a Service

With the rise of Software as a Service (SaaS) businesses, we have seen a similar rise in open source communities adopting this as a model. In its purest form, the software itself is made available under an open source license, which you could take and run on your own systems, at your own expense. You could also purchase the same from the business as a Software as a Service subscription. This was the original model for Chef Software, as an example. MongoDB offers their database as a service, Redis Labs offers their database as a service - the list is long. The challenge with this model as a primary method is around whether the value is captured by the community or not. Since the software in question is open source, if the license is permissive enough, anyone can make it available, with no obligations to contribute back. This becomes a variant of the free software island problem - the upstream software is clearly open source, but as we monetize the various services downstream, our incentive is to keep less and less of the services functionality free, if we can. The Affero GPL was created specifically to deal with this problem, and more recently you have attempts like the Commons Clause, which make a specific attempt to limit the ability for large service providers to monetize open source communities. From a sustainability point of view, a model where the software is 100% open source, and the only proprietary software is around the specifics of a given service implementation meets all the criteria - anyone who wanted to run the software as a service could, they need only put in the effort to run the service itself. When we start to have competing services, we get the same incentives we get with the permissive free software islands: the best strategy is to differentiate your service through proprietary extensions, while others build up the core. If instead we limit ability of community members to launch competing services on the software, we run into trouble with our conception of what a just and sustainable community is: we hold back the right to monetize for a specific company, clearly a setup that fails the difference principle.

Since I first wrote that paragraph, MongoDB has relicensed under an even stronger version of copyleft, called the SSPL. This license requires not only the application itself to be open sourced under the same license if it is accessed over the network - it requires that the supporting software required to build the service is open sourced as well. This is an even further extension of the same problem - MongoDB’s hosted service, Atlas, clearly isn’t having the same terms applied to it. If it was, our analysis would be different - it would clearly pass this test, since there is equality in the application of the license.

Donations

Donations are a classic model of funding open source. A great modern example of this is webpack, which uses the Open Collective platform to handle not only collecting the donations, but how they are distributed amongst the contributors. This makes it particularly attractive, from a Rawls perspective, due to the ability for individual contributors to receive a portion of the collective funding. Contributing to webpack immediately brings you to the table as a possible recipient of benefit from webpack’s donations. A more historical example is Vim, which has long accepted donations - originally to fund Vim’s continued development by its primary author, Bram Moolenaar, and once he had a stable job, funneled to a charity for children in Uganda. Clearly the model followed by webpack can create a sustainable open source community under our terms so far. Vim is a more interesting case - Bram Moolenaar is the sole primary developer of Vim, and while he takes patches, it is clearly his project (and always has been.) The result is that, if you wanted to grow in your ability to influence Vim, or to grow to the level where you could take donations to fund your own work, Vim’s community model (or lack thereof) precludes you from doing so effectively. For the donation model to be a component of a sustainable open source community, it requires the kind of open ability to distribute the funding seen with webpack, or at least an open enough governance model that individuals could be funded for their work, with a reasonable ability to assume it can be completed.

Support

A similarly tested strategy is the support model. An example of this model was the relationship between XenSource and Xen. Xen is an open source hypervisor originally built by researchers at the University of Cambridge, along with industry collaborators. XenSource was founded to commercialize the open source Xen code, and initially offered only paid support for the hypervisor. Over time, XenSource moved to being a loose open core company. The hypervisor itself remained free, but XenSource (and Citrix, after their aquisition of XenSource in 2007) built proprietary products that sat on top of it designed to appeal to the large enterprise. This is a common transition with the support-only model: since the hope is that your software will be useful, and will continue to improve, the business model of selling support is directly at odds with the user experience of the software. As we make it easier to use, we also make the need for support lower. As a result this model has historically never been sustainable alone, if the goal is to drive significant amounts of capital into the software. It instead morphs into an open core strategy (by far the most common) or into a free software product strategy. Clearly, the support model by itself meets all the requirements of a sustainable open source community, at least for the core project, but might not result in a sustainable business strategy, depending on the growth requirements of the business or other ecosystem dynamics.

Citrix appears to have recognized this over time, as they announced that the proprietary components built on top of the Xen project would be released as open source on June 24, 2013. The community reaction was mixed, and one group announced that they would fork the XenServer code in 2017, creating XCP-ng.

Free Software Product

Which brings us to the free software product model. This is the model that, in my opinion, is the least understood in our current landscape. The best example of a free software product company is Red Hat. They produce 100% free software, but they produce only proprietary distributions of their software: they leave the creation of 100% free distributions to others (there are community efforts funded by Red Hat, such as Fedora, and most recently CentOS.) The side effect is that Red Hat is always the upstream for their software, regardless of its origin - Red Hat Enterprise Linux is a collection of free software, bundled together, supported, and distributed by Red Hat, but with commercial terms attached. You are free to make a derivative work of Red Hat Enterprise Linux - provided you remove any of the Red Hat trademarks from your derivative. The resulting work benefits from all the effort Red Hat puts in to Enterprise Linux, but requires a reasonable amount of effort to produce (CentOS is one example, Oracle Enterprise Linux is another.) You can see a similar transformation take place with other products, even those not primarily produced by Red Hat, such as Kubernetes. Red Hat’s Kubernetes distribution, OpenShift, takes the upstream Kubernetes (itself a free software island) and produces an open source derivative with extra functionality. They then sell that distribution as commercial software - as a hosted service, and as on premises software. By committing 100% of the software they produce into open source, even when they create a proprietary distribution of a free software island, they become a de-facto new upstream.

No company has more mythology about why it is successful than Red Hat, and all of them have some element of truth to them. Over the course of writing this document, I’ve heard answers that range from “it works because it is so broad”, “it works because IBM chose them”, “it works because people pay for operating systems”, “it works because the enterprise needs one throat to choke”. All of these things are real, but I think the root reason it works is because of the dynamics above. Red Hat has all the benefits of a proprietary software company: they sell 100% of the value of the software they produce, they provide absolutely no support to non-paying customers, and you cannot receive their valuable goods without paying them for the privilege. They also get all the benefits of being a free and open source company: development can happen in the open, they can build coalitions who contribute to moving the software forward (which improves their proprietary distribution,) and they can create new products when and wherever they wish, pulling directly from the existing free software ecosystem. They produce proprietary distributions of free software projects: they build free software products.

When organizations try and follow the “Red Hat Model”, they typically are really following the support model. Indeed, that’s a part of the value proposition for Red Hat products - but it isn’t the entire value proposition. What differentiates the free software product model from a pure support model?

Free software products have trademarked, proprietary distributions, with commercial terms attached.
Free software products (may) have 100% open source distributions, but they must use different trademarks and naming conventions, and receive no direct customer support or interaction from the upstream. They are strictly downstream repackaging of the proprietary upstream distribution. This is true regardless of which source code repository is being committed to - the user relationship is defined in terms of the commercial product, not the free software project.

These two attributes are key to the free software product model. Red Hat Enterprise Linux is a proprietary, commercial distribution of Linux. CentOS is a 100% free distribution, derived from Red Hat Enterprise Linux. OpenShift is a proprietary, commercial distribution of Kubernetes. OKD is a 100% free community distribution of OpenShift. Important in these sentences is which comes first - in all cases, the proprietary distribution is the upstream! Anyone who is using CentOS would say they are using it because they want to be using Red Hat Enterprise Linux: they just, for whatever reason, do not want to pay the commercial terms required by Red Hat for the privilege. The same would be true for OKD; no OpenShift user would say they are using the commercial version of OKD. Instead, they would say they are using the free version of OpenShift. This is the key element in a free software product model, and it is the one that is the least understood in the industry broadly.

How does this model stack up, from a Rawls point of view? By committing 100% of the software to open source, the model ensures basic liberty completely, and it avoids any of the difficulties of drawing arbitrary lines around where the community stops and the commercial interests begin we see with free software islands or the open core models. Assuming the governance model meets our earlier criteria, there is nothing in the model that doesn’t meet both the equal liberty principle and the difference principle. If, for whatever reason, you need to create a similarly proprietary distribution of the software, you are completely free to do so, and you can do so regardless of the circumstances you start out in.

Sustainable models

What attributes can we pull from this analysis? When it comes time to consider how we will introduce capital into the system, we have to make a series of choices (each of which assumes the project has clear and just governance, as we discussed above):

If the software is never intended or desired to be used in a direct business context, they should choose a transparent donation model.
If the software is self contained, but useful primarily only as a component in a larger set of software, then they should choose to create a free software island with the strongest copyleft license that is applicable. Contributions flow back through downstream commercialization and the copyleft contribution incentives.
If the software is broadly applicable, and intended to be used in a direct business context, they should choose the free software product model.
If the software is broadly applicable, and intended to be used as a widely adopted standard, with multiple competing commercial offerings, they should choose free software island model with the strongest licensing model that supports the standards adoption.

From a sustainable open source community point of view, all the other models leave something to be desired. They may require us to subdivide our community, a-la the free software island approach applied to larger pieces of software, or those with direct value. They lead to incentivizing the creation of proprietary forks, pushing the project to be less free as more capital joins the system, a-la the open core models and the SaaS model.

This leads to our final two principles of a sustainable open source community:

Any commercial activity around the software must further the sustainability of the community, and the potential for commercial benefit must be available to all.
The incentives in any commercial models must bend away from the creation of proprietary downstream software.

The second point merits more inspection. We see that when we create the lines of our community such that no commercial interests are allowed to interfere with it, we can create communities that meet all of our criteria - but that start to fall down when we consider the second part of our communities desires, which are “whatsoever else they might want”. As community members, we might very well decide that we want to benefit monetarily from the software - through consulting, through starting a software business. Existing businesses want to create communities around their software, like Kubernetes, in order to increase their own competitive position. The lines are not clear here - how do we know, in any given case, if the decisions we make will harm the long term sustainability of our community?

It is to this end the second point exists. If we are going to have commercial activity around the communities software, the incentives must lead towards the creation of more of the software the community desires. If instead it incentivizes the creation of proprietary software, then we likely end up in a kind of open source stasis - either the upstream does not have valuable features (who wouldn’t, for example, want half the latency, twice the performance, and simplified operations of Datastax compared to Cassandra), or those features are hidden away behind competing as-a-service offerings. Our community may be sustainable, but it will be comparatively anemic.

I stop short of advocating for copyleft in all situations. The reason, for me, comes back around to Rawls. I don’t know the situation of every person who may need to join the community, and I don’t know the conditions of their lives that they wish to improve. What I do know is, if I use a strong copyleft, I’m narrowing my conception of what’s viable for them to do with the software, frequently in a commercial context. I find the argument that we should limit the terms of the software, in all cases, as copyleft does to be uncompelling in those conditions - the difference principle might compel me to use a non copyleft license, so that they have the freedom to make the decisions that best benefit them. So the statement is that we must choose models that bend away from the creation of proprietary software - where “bend” implies that we may, in fact, not decide to completely remove that option, but instead to ensure the incentives for that option are bad (as the free software product model does).

Docs: The Way Forward

Thu, 29 Nov 2018 14:37:03 -0800

How do we move forward?

We can pull all of this together with set of of sustainable open source community principles - these are the guidelines we should follow if we want to create a sustainable open source community. Then we can create specific implementations of these principles for our communities - social contracts that spell out the communities’ intentions, their relationship to monetization, and the principles upon which they will thrive: their community social contract.

I don’t pretend to know or have seen all the possible models, or have a perfect understanding of what happens when we build intentionally sustainable open source communities. My hope is that we can help each other, and the industry at large, understand that communities are about people coming together with common cause, and helping each other day by day. That the value of development in the commons isn’t just a technically superior model: it’s also the right social and ethical model.

I believe that if we do that, we will start to see a reverse of the trend where the most closed companies have the best outcomes. Instead, we will see that the companies who are the best participants in the community, who build the best, most sustainable model of helping their users and customers solve their problems, will be the winners. There is no comparison to the impact we have on each other when we form supportive, inclusive, meaningful communities. I hope you’ll join me.

For next steps: explore the principles, business models

Docs: None

Wed, 09 Jan 2019 00:00:00 +0000

No business model

This is a common archetype for Sustainable Free and Open Source Communities. The business model is to not have a business model. That is okay, because not every sustainable open source project needs or wants a business model.

In this case the project has set up means and rules of collaboration, has a formal membership, usually without a formal position of authority or any other hierarchy and does not deal with monetary contributions.

Sustainability in this non-model focuses on collaborator growth (quality and quantity) and shared responsibility to address its biggest risk: contributor churn.

Who uses it?

When should it be used?

In the early phase of projects when it’s not clear that the idea/implementation is a viable option in the free software ecosystem. Or when it’s clear from the beginning, that the target audience is rather limited in size.

Sometimes this model is also used as a way out of entrenched corporate influence. Incubating a new project, while blacking out monetary interests, trying to supersede the fought-over-project by technical means. Kind of a fork of the problem space (not the technology), resetting the relationship of the involved parties. A prominent example for this would be systemd or the GNOME desktop environment.

What kind of monetization is possible?

Cash flow is avoided in this model because there is no legal entity behind the project (just individuals) that can handle the added complexity (control, reporting, taxes etc.) that monetization brings.

The individuals involved cover the development costs for the project by donating their time. Infrastructure costs are avoided by utilizing free to use plans of services like gitlab/github, travis-ci/circle-ci, netlify etc. or by donations of goods by members (like paying for a domain name etc.).

Does this model help create a Sustainable Free and Open Source Community?

Yes. This model can be applied for a very long time as long as the community sucessfully addresses contributor churn.

Docs: Support

Thu, 06 Dec 2018 14:37:03 -0800

Software is available under an open source license, and support is provided for a fee.

The Support model is one where the software is available under an open source license, but in order to have the company available to answer questions, assist in implementation, etc., you must purchase a support contract.

This model is often confused for the Free Software Product model.

Who Uses it?

XenSource (very early on - moved to loose open core over time)
Ntop
Zabbix
MySQL

When should it be used?

This is typically an early way to bring in revenue for an open source project. If/when the company or project needs to scale, it tends to transition into another model.

What kinds of monetization is possible?

Any, essentially.

Does this model help create a Sustainable Free and Open Source Community?

Yes.

Docs: Tight Open Core

Thu, 06 Dec 2018 14:37:03 -0800

Software has primary functionality covered under an open source license (the core) but has direct (often critical) features that are only available under a proprietary license.

Tight Open Core is a model where the software has its primary functionality covered under an open source license (the “core”), but has direct (often critical) features that are only available under a proprietary license.

Take, for example, the feature of authentication and authorization. Some amount of these are critical for almost all software. In a Tight Open Core model, this functionality will not exist in the open source core: instead, it will be pushed to either proprietary plugins or exist only in fully proprietary builds.

Who Uses It?

When should it be used?

Frequently used by venture backed startups, with a single company putting in the bulk of the engineering and product resources. The goal is to have successful enough core offering to generate substantial demand for the proprietary functionality.

What kind of monetization is possible?

These types of software are usually intended to be monetized from the beginning, although some (like Elastic) have shifted to this model over time. With this model, it is easier to determine if a given piece of functionality should be in the core or not: if it is critical to the success of your target market, it should be proprietary.

Does this model help create a Sustainable Free and Open Source Community?

No. There is evidence it is more effective as a business model than its cousin, loose open core. However, the dynamics of keeping vital functionality out of the core means that, should the community decide to replicate the feature, it is directly at odds with the company’s monetization model.

Docs: As a Service

Thu, 06 Dec 2018 12:27:40 -0800

The As a Service model is for software released under an open source license, and available as a service by the company.

The As a Service model is when the software is released under an open source license, and available for anyone to run, while also being made available As a Service by the company.

Who Uses it?

When should it be used?

When the software is primarily consumer oriented, or has a large operational overhead. The goal here is that the software has the simplest on-ramp possible, and requires no effort to maintain over time.

What kind of monetization is possible?

In its most pure form, such as Discourse, the software is always 100% free. That means that, while there is often a single company offering it as a service, the community itself is free to do so as well.

In other cases, the software will be covered under an aggressive form of copyleft, potentially combined with dual licensing, or non-free licenses (such as the commons clause) may be used to create a monopoly on offering the software as a service.

Does this model help create a Sustainable Free and Open Source Community?

Maybe. With the example of Discourse above, the answer is yes. The community is sustained through the service, but any member of the community would be free to compete. With any model that uses dual licensing combined with aggressive copyleft, or non-free licenses, it trades the fundamental liberties in the core commitment for revenue.

Docs: Code of Conduct

Thu, 06 Dec 2018 12:27:40 -0800

This page details guidelines for interaction and behavior in the SFOSC community.

Contributor Covenant Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

Using welcoming and inclusive language
Being respectful of differing viewpoints and experiences
Gracefully accepting constructive criticism
Focusing on what is best for the community
Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

The use of sexualized language or imagery and unwelcome sexual attention or advances
Trolling, insulting/derogatory comments, and personal or political attacks
Public or private harassment
Publishing others’ private information, such as a physical or electronic address, without explicit permission
Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at adam@stalecoffee.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq

Docs: Contributing

Thu, 06 Dec 2018 12:27:40 -0800

This page includes information about contributing to SFOSC

Request for Contributions

We would love to have you help us evolve the principles, write new social contracts, and further explore what it means to create sustainable free and open source communities.

In particular, we seek the following types of contributions:

ideas: participate in an issues thread or start your own to voice your idea
copy editing: contribute your expertise by helping us expand, clarify and proofing our content
code: improve the design, usability and functionality of the sfosc page
artwork: contribute graphics or any other artwork improving the presentation of sfosc

Read this guide on how to do that.

How to Contribute Ideas

Prerequisites: familiarity with GitHub Issues.

Our community mainly communicates over github issues threads. Please voice any idea, criticism or feedback in them so we can have an open discussion. Of course you can also feel free to contact any of our members privately if you think this is necessary.

How to Contribute Code

Prerequisites: familiarity with GitHub Pull Requests

If you want to contribute code, fork the repository and make a pull-request with your changes.

If you want to view/test your changes locally before, you can build this static web page with hugo, please check their extensive documentation on how to install and use this site generator.

A sfosc member will review your pull-request. And if the pull request gets a positive review the reviewer will merge it.

However, please bear in mind the following things:

Discuss Large Changes in Advance

If you see a glaring flaw within the SFOSC, resist the urge to jump into the code and make sweeping changes right away. We know it can be tempting, but especially for large, structural changes it’s a wiser choice to first discuss them in the issue list. It may turn out that someone is already working on this or that someone already has tried to solve this and hit a roadblock, maybe there even is a good reason why that flaw exists. If nothing else, a discussion of the change will usually familiarize the reviewer with your proposed changes and streamline the review process when you finally create a pull request.

A good rule of thumb for when you should discuss on the issue list is to estimate how much time would be wasted if the pull request was rejected. If it’s a couple of minutes then you can probably dive head first and eat the loss in the worst case. Otherwise, making a quick check with the other developers could save you lots of time down the line.

Small Commits & Pull Request Scope

A commit should contain a single logical change, the scope should be as small as possible. And a pull request should only consist of the commits that you need for your change. If it’s possible for you to split larger changes into smaller blocks please do so.

Limiting the scope of commits/pull requests makes reviewing much easier. Because it will usually mean each commit can be evaluated independently and a smaller amount of commits per pull request usually also means a smaller amount of code to be reviewed.

Proper Commit Messages

We are keen on proper commit messages because they will help us to maintain this in the future.

The title of your commit should summarizes what has been done
- If the title is to small to explain what you have done then elaborate on it in the body
Explain why you have changed this instead of the how. This is the most important content of the message.
Explain potential side-effects of this change, if there are any

Please also:

Leave a blank line between the commit subject and body

Tools like rebase could not work properly otherwise.

Mention related issues

If this commit fixes an issue you need to mention it like Fixes #1234

Give kudos to Co-authors

If the commit has more than one author tag them with Co-authored-by: name <name@example.com>.

Try that the commit subject is not longer than 50 characters
Try that each line of the commit body is not longer than 72 characters

How to Conduct Yourself

Please make sure that while contributing you follow our Contributor Covenant Code of Conduct!

Happy Hacking! - :heart: Your SFOSC Team

Docs: Donations

Thu, 06 Dec 2018 12:27:40 -0800

When a system of donations is set up to sustain a project.

Not really a “business model”, but let’s go with it anyway. The donations model is when the project sets up a system of donations, which are used to sustain the project.

Who uses it?

Vim
Webpack

When should it be used?

When the project is core infrastructure, primarily run by volunteers, or simply to do good in the world.

What kind of monetization is possible?

Anything that is valid under the license. In this model, though, sponsorship and individuals alike are solicited to cover the infrastructure and development costs for the project.

Take a look at the Webpack Open Collective for a great example of the donation model in action.

Does this model help create a Sustainable Free and Open Source Community?

Yes.

Docs: Dual Licensing

Thu, 06 Dec 2018 12:27:40 -0800

The software is released under an open source license, but has a single entity with full control of the software’s copyright.

Dual Licensing is a model where the software is released under an open source license, almost always a copyleft license, but has a single entity with full control of the software’s copyright. This enables the company to re-license the software as they see fit - either to sell it under a non-copyleft license, to run it as a service, or to sell proprietary versions, while restricting the rights of others to do the same.

Who Uses it?

MySQL (as a secondary model)
MongoDB

When should it be used?

A tool used primarily by venture backed startups, with a single company in control of the asset. The goal here is that the software is useful to a wide market with the copyleft terms attached, but for certain segments of the market, or to create your own proprietary derivative, you retain the rights to remove the copyleft.

What kind of monetization is possible?

Depending on the type of copyleft license, it ranges from simply selling identical software without copyleft terms (for embedding, as an example), to being allowed to run the software as a service, to being allowed to build fully proprietary distributions with enhanced functionality.

In any case, it is used to create a functional monopoly on monetization for the company.

Does this model help create a Sustainable Free and Open Source Community?

No. It trades the fundamental liberties in the core commitment in exchange for revenue.

Docs: Free Software Island

Thu, 06 Dec 2018 12:27:40 -0800

A project (usually enabled by a foundation) where everyone agrees that the software is created purely for the public good.

A Free Software Island is a project, usually enabled by a foundation, where everyone agrees the software is created purely for the public good. Individuals and businesses alike agree to co-operate with each other on the software that is contained on the island, for mutual benefit.

Who uses it?

Projects like Envoy were free software islands even before they joined a foundation (the CNCF in this case).

When should it be used?

If the project will have many collaborators, often large institutional ones, then a free software island may be the best home for it. While being on a free software island does not guarantee this kind of collaboration, it is designed for it.

What kind of monetization is possible?

Often, there is no direct monetization of the projects allowed at all. The Apache Foundation, for example, is very clear on this.

Instead, there are often downstream monetization of the software. For example:

The relationship between Apache Cassandra and DataStax - Cassandra is upstream, and DataStax is a proprietary downstream for Cassandra.
Kubernetes has a myriad of downstream monetization - companies with proprietary software offerings built on top, open source product extensions such as OpenShift, and cloud providers offering it as a service.

Does this model help create a Sustainable Free and Open Source Community?

Yes. The only risks in this model are that it only affirms the rights of the community within the island itself - it may result in the creation of more proprietary software, outside the community’s sphere of influence.

Docs: Free Software Product

Thu, 06 Dec 2018 12:27:40 -0800

Has 100% of the software covered by an open source license, but distributes the software as a supported product under a proprietary license.

The Free Software Product model has 100% of the software covered by an open source license, but distributes the software as a complete, supported product under a proprietary license.

Free Software Product companies use their trademark rights, along with the license of the software itself, to create proprietary derivatives. If there is a 100% open source distribution, it uses different trademarks and naming conventions, and receives little or no direct support for users from the upstream.

A cornerstone of this model is that the company produces little or no proprietary software. It allows the community to collaborate and makes it harder for proprietary derivatives to thrive.

Who Uses It

Red Hat

When should it be used?

When a single company provides the bulk of the effort to create and sustain the project, and has a clear target market for the product (typically the large enterprise).

What kind of monetization is possible?

Any kind of monetization is possible on the product. Because it is being distributed under proprietary terms, the options for monetization are unlimited. For those who might wish to create downstream versions of the project, they too are free to monetize as they see fit.

Does this model help create a Sustainable Free and Open Source Community?

Yes. By keeping 100% of the software open source, and not producing any proprietary features, the community is free to collaborate with the upstream. A 100% free downstream distribution can be created, and distributed - optionally with complete monetization.

Docs: Loose Open Core

Thu, 06 Dec 2018 12:27:40 -0800

Primary functionality is covered under an open source license (the core), and proprietary software is wrapped around it.

Loose Open Core is a model where the software has its primary functionality covered under an open source license (the “core”), with proprietary software wrapped around it. This model encourages widespread distribution of the core software, and tries to ensure that enough value exists in the proprietary software around it to convince their target market to make a purchase.

Who uses it?

When should it be used?

This is model that is frequently used by venture backed startups, where a single company puts in the bulk of the engineering and product resources. If the core project is successful, it leads to a large funnel of users that can then be sold the proprietary software.

If the core of the software has broad applicability to a wide market, and you can envision a proprietary product targeted at some segment of the market, this model can work well.

What kind of monetization is possible?

These communities are often monetized from the beginning, or at least are intended to be. The difficulty with this model is that it can be hard to determine where the right line is for a given feature - does it belong to the proprietary software, or the open core?

Typically, there is a single company that monetizes the core software.

Does this model help create a Sustainable Free and Open Source Community?

Maybe. If we treat the core software as essentially a free software island with a single downstream derivative, then yes, assuming others are allowed to also build proprietary software around the core.

However, this is often murky - since the company’s strategy depends on convincing a segment of the population that they must purchase the proprietary software, it will be easy for the company to turn to other models, which may mean it is no longer sustainable by the community.

Docs: Membership

Thu, 06 Dec 2018 12:27:40 -0800

This page includes information about membership in SFOSC

Membership in the SFOSC

Welcome! Anyone who is interested in contributing to the SFOSC in any way is welcome to become a member.

Membership is not a requirement for participating in the community. Members may be consulted about governance of the community. For example through votes. The CONTRIBUTING GUIDELINES explain several ways you can contribute regardless of membership.

Membership in the community is broad based, available to anyone who is participating in any fashion. Requirements for membership involve a minimal amount of verification of identity, and proof of engagement with the community. Membership consists solely of individuals - there are no corporate community members.

At the moment, the only privilege membership brings is being able to vote for the project leader. And, of course, the glory of having your name appended to this file.

Applying

To apply for membership, send a pull request to this file, adding your name and GitHub username.

Please mention why you became interested in SFOSC and share some related work. This is optional though, please share only as much as you would like to.

Existing members will review your application. The aspects we look for currently are: - Full name and GitHub username, to serve as minimal verification of identity. - You have either engaged with SFOSC directly, or have related experience we can verify. If this experience is not easily found from your GitHub profile, please mention it as part of the pull request.

Interested, but not sure if you meet the requirements? Go ahead and submit your pull request! We’re glad you’re interested and there to help.

Members

Adam Jacob (adamhjk)
Karl Amrhein (karlamrhein)
Elias Secchi (eliassecchi)
Camille Moulin (camillem)
Daniel Thompson-Yvetot (nothingismagick)
Vanessa Sochat (vsoch)
Chris Alfano (themightychris)
Nick Kellett (nickkellett)
Marc Laporte (marclaporte)
Robin van Boven (beanow)

Docs: Social Contract

Thu, 06 Dec 2018 12:27:40 -0800

This page includes information about SFOSC social contracts.

Introduction

This document describe the social contract for the community around a piece of open source software (“the software”). It lays out the moral and ethical rules the community agrees to in order to ensure a long, healthy, sustainable life for the software.

It is not a legal agreement, although sections of it reference legal agreements. It is a moral and ethical one - it is the foundation upon which the community is built.

By joining the community, you agree to the rules and beliefs outlined in this social contract.

Principles

We follow the principles of sustainable free and open source communities.

We are a unified body of individuals, scattered throughout the larger society, who work in support of the creation, evolution, use, and extension of the software; while ensuring its longevity through meeting the needs of the present without compromising the ability of the community of the future to meet its own needs.

We want the software to exist, to solve our problems, to continue to improve, and to be available for our use. Therefore, we commit that we will uphold these four freedoms for all, under all circumstances:

The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1).
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3).

We do this because:

We believe that software is better when it is produced in the commons.
We believe that sustainable communities are based on just and fair institutions.
We value the ability of every person to use the software to better their own lives.

Governance

Code of Conduct

To ensure that all people are welcome, treated fairly and safely, this community has a code of conduct, published at CODE OF CONDUCT. It applies equally to all members of the community, both on-line and in person. Membership and participation in the community requires following the Code of Conduct.

Membership

Guidelines for membership can be found at MEMBERSHIP GUIDELINES.

Voting

Periodically, the membership may be requested to vote in elections, or on a referendum on an important issue. Each member is entitled to a single vote, and all votes count equally.

Guidelines for voting can be found in VOTING GUIDELINES.

Leadership

Leadership in the community is based on a strong executive model. The Project Leader will be elected by a simple majority vote according to the voting guidelines. The Project Leader will serve for 1 year, at the end of which a new election for Project Leader will be held.

The Project Leader has broad authority to manage the project as they see fit, to delegate positions of authority, and to enact new governance rules. The exception is amending this social contract. This can only be done with a ³⁄₄ vote of the membership.

A new election can be held for the Project Leader at any time, regardless of term, based on a simple majority vote of the membership.

The full set of guidelines for the Project can be found at PROJECT RULES.

Licensing, Copyrights, Patents, and Trademarks

Software License

All software produced by the community will be published under the SOFTWARE LICENSE. All contributors to the software agree to publish their work under this license, and to have it included in any distributions or derivatives allowed under the same terms.

Copyrights

All copyrights remain the property of the original copyright holder, under the terms of the SOFTWARE LICENSE.

Patents

Any patents included in the software must be made available under the same terms as the SOFTWARE LICENSE.

Trademarks

Any trademarks that may exist, relating to the software directly, are the ethical property of the community itself. Their use in the software is made available under the same terms as the SOFTWARE LICENSE.

Further details can be found in the TRADEMARK POLICY.

Economic Sustainability

Community Intent

Any commercial activity around the software should, in part, further the sustainability of the community. The potential for economic benefit is available to all members of the community equally.

Donations

This project will be sustained through a donation model. Currently the project has no expenses, so no system of donations is yet available.

Docs: Trademark

Thu, 06 Dec 2018 12:27:40 -0800

This page includes information about SFOSC trademarks.

Trademark Policy

The Sustainable Free and Open Source Community, and the SFOSC, are not currently trademarked. We do ask that, if you want to republish this content, you do so in line with the terms of our license.

Docs: Voting

Thu, 06 Dec 2018 12:27:40 -0800

This page details guidelines for voting in SFOSC.

Voting Guidelines

Every member in the MEMBERSHIP file is allowed one vote. We will use Helios to organize the actual vote, and certify the results.

Docs: Donation based Social Contract

Thu, 29 Nov 2018 12:13:32 -0800

Introduction

This document describes the social contract for the community around a piece of open source software (“the software”). It lays out the moral and ethical rules the community agrees to in order to ensure a long, healthy, sustainable life for the software.

It is not a legal agreement, although sections of it reference legal agreements. It is a moral and ethical one - it is the foundation upon which the community is built.

By joining the community, you agree to the rules and beliefs outlined in this social contract.

Principles

We follow the principles of sustainable free and open source communities.

The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1).
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3).

We do this because:

We believe that software is better when it is produced in the commons.
We believe that sustainable communities are based on just and fair institutions.
We value the ability of every person to use the software to better their own lives.

Governance

Code of Conduct

To ensure that all people are welcome, treated fairly and safely, this community has a code of conduct, published at [CODE OF CONDUCT]. It applies equally to all members of the community, both on-line and in person. Membership and participation in the community requires following the Code of Conduct.

Membership

Guidelines for membership can be found at [MEMBERSHIP GUIDELINES].

Voting

Periodically, the membership may be requested to vote in elections, or on a referendum on an important issue. Each member is entitled to a single vote, and all votes count equally.

This community uses [VOTING SYSTEM] for voting, and guidelines for voting can be found at [VOTING GUIDELINES].

Leadership

Leadership in the community is based on a strong executive model. The Project Leader will be elected by a simple majority vote according to the voting guidelines. The Project Leader will serve for [TERM], at the end of which a new election for Project Leader will be held.

A new election can be held for the Project Leader at any time, regardless of term, based on a simple majority vote of the membership.

The full set of guidelines for the Project can be found at [PROJECT RULES].

Licensing, Copyrights, Patents, and Trademarks

Software License

All software produced by the community will be published under the [SOFTWARE LICENSE]. All contributors to the software agree to publish their work under this license, and to have it included in any distributions or derivatives allowed under the same terms.

Copyrights

All copyrights remain the property of the original copyright holder, under the terms of the [SOFTWARE LICENSE].

Patents

Any patents included in the software must be made available under the same terms as the [SOFTWARE LICENSE].

Trademarks

Further details can be found in the [TRADEMARK POLICY].

Economic Sustainability

Community Intent

Any commercial activity around the software should, in part, further the sustainability of the community. The potential for economic benefit is available to all members of the community equally.

Donations

This project is directly sustained through a donation model. Donations should can be made through [DONATION SYSTEM]. Further details can be found in the [DONATION POLICY].