From 553b1301ded6be9720cd3139aedc94ca4820397e Mon Sep 17 00:00:00 2001 From: Adam Jacob Date: Fri, 30 Nov 2018 15:02:55 -0800 Subject: [PATCH] Initial Commit First commit for the SFOSC website. --- .gitignore | 3 + archetypes/default.md | 6 + config.toml | 14 ++ content/_index.md | 25 ++++ content/business-models/_index.md | 13 ++ content/governance-models/_index.md | 13 ++ content/principles/_index.md | 35 +++++ content/sfosc-book/_index.md | 25 ++++ content/sfosc-book/business-models.md | 86 +++++++++++ content/sfosc-book/conception.md | 24 ++++ .../contribution_and_distribution.md | 28 ++++ content/sfosc-book/governance.md | 68 +++++++++ content/sfosc-book/institutions.md | 37 +++++ content/sfosc-book/introduction.md | 23 +++ content/sfosc-book/motivations.md | 43 ++++++ content/sfosc-book/rawls_for_foss.md | 45 ++++++ content/sfosc-book/the_way_forward.md | 13 ++ content/social-contracts/_index.md | 13 ++ content/social-contracts/donation.md | 134 ++++++++++++++++++ layouts/contract.html | 15 ++ layouts/contract_parts/principles.md | 29 ++++ layouts/partials/logo.html | 1 + layouts/partials/principles.html | 29 ++++ themes/hugo-theme-learn | 1 + 24 files changed, 723 insertions(+) create mode 100644 .gitignore create mode 100644 archetypes/default.md create mode 100644 config.toml create mode 100644 content/_index.md create mode 100644 content/business-models/_index.md create mode 100644 content/governance-models/_index.md create mode 100644 content/principles/_index.md create mode 100644 content/sfosc-book/_index.md create mode 100644 content/sfosc-book/business-models.md create mode 100644 content/sfosc-book/conception.md create mode 100644 content/sfosc-book/contribution_and_distribution.md create mode 100644 content/sfosc-book/governance.md create mode 100644 content/sfosc-book/institutions.md create mode 100644 content/sfosc-book/introduction.md create mode 100644 content/sfosc-book/motivations.md create mode 100644 content/sfosc-book/rawls_for_foss.md create mode 100644 content/sfosc-book/the_way_forward.md create mode 100644 content/social-contracts/_index.md create mode 100644 content/social-contracts/donation.md create mode 100644 layouts/contract.html create mode 100644 layouts/contract_parts/principles.md create mode 100644 layouts/partials/logo.html create mode 100644 layouts/partials/principles.html create mode 160000 themes/hugo-theme-learn diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..6d1a2bb --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +.DS_Store +tags +public diff --git a/archetypes/default.md b/archetypes/default.md new file mode 100644 index 0000000..00e77bd --- /dev/null +++ b/archetypes/default.md @@ -0,0 +1,6 @@ +--- +title: "{{ replace .Name "-" " " | title }}" +date: {{ .Date }} +draft: true +--- + diff --git a/config.toml b/config.toml new file mode 100644 index 0000000..3214f11 --- /dev/null +++ b/config.toml @@ -0,0 +1,14 @@ +baseURL = "https://sfosc.github.io/" +languageCode = "en-us" +title = "Sustainable Free and Open Source Communities" +theme = "hugo-theme-learn" + +[params] +author = "The Sustainable Free and Open Source Community" +description = "Guidelines for building sustainable free and open source communities" +disableBreadcrumb = false +themeVariant = "blue" +editURL = "https://github.com/sfosc/sfosc.github.io/edit/master/content/" + +[outputs] +home = [ "HTML", "RSS", "JSON" ] diff --git a/content/_index.md b/content/_index.md new file mode 100644 index 0000000..1c86789 --- /dev/null +++ b/content/_index.md @@ -0,0 +1,25 @@ +--- +title: "SFOSC" +date: 2018-11-29T11:01:38-08:00 +--- + +# Sustainable Free and Open Source Community + +Welcome! This is a place dedicated to the discussion, creation, and evolution of Sustainable Free and Open Source Communities. We are organized around the development of a set of shared [principles]({{%ref "principles" %}}) that we believe lead to healthy, sustainable open source communities. + +Our conception of community is an expansive one - it covers developers, users, evangelists, venture capitalists - anyone who believes that software is better when it is built in a community, and that communities are formed because of a shared understanding between people. + +In addition to the [principles]({{% ref "principles" %}}), we publish a set of ready to use [social contracts]({{% ref "social-contracts" %}}). These social contracts can be adopted by free and open source software projects, and go in to detail the expectations of the community around: leadership, contribution, codes of conduct, monetary investment, and more. + +If you're considering starting an open source project, and you intend to start a business around it, you might be interested in our [explanation of the various open source business models]({{% ref "business-models" %}}). This includes why some create more sustainable communities than others. + +Finally, you might [want to read the book]({{% ref "sfosc-book" %}}) on the thought process and research that went in to the creation of SFOSC. + +## Join us + +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. There are a couple ways to get started: + + * Send us a [pull request for this website](https://github.com/sfosc/sfosc.github.io)! + * Start a conversation by [filing an issue](https://github.com/sfosc/sfosc.github.io/issues) + +Is itself a Sustainable Free and Open Source Community, using the [Donation Social Contract]({{% ref "social-contracts/donation.md" %}}). The current leader is Adam Jacob, but we'll be having our first election soon. diff --git a/content/business-models/_index.md b/content/business-models/_index.md new file mode 100644 index 0000000..f9d4057 --- /dev/null +++ b/content/business-models/_index.md @@ -0,0 +1,13 @@ ++++ +title = "Business Models" +date = 2018-11-29T12:13:04-08:00 +weight = 5 +chapter = true +pre = "X. " ++++ + +### Chapter X + +# Some Chapter title + +Lorem Ipsum. \ No newline at end of file diff --git a/content/governance-models/_index.md b/content/governance-models/_index.md new file mode 100644 index 0000000..7981731 --- /dev/null +++ b/content/governance-models/_index.md @@ -0,0 +1,13 @@ ++++ +title = "Governance Models" +date = 2018-11-29T15:52:08-08:00 +weight = 5 +chapter = true +pre = "X. " ++++ + +### Chapter X + +# Some Chapter title + +Lorem Ipsum. \ No newline at end of file diff --git a/content/principles/_index.md b/content/principles/_index.md new file mode 100644 index 0000000..f02891a --- /dev/null +++ b/content/principles/_index.md @@ -0,0 +1,35 @@ ++++ +title = "Principles" +date = 2018-11-28T15:40:54-08:00 +weight = 1 ++++ + +## Preamble + +We are a unified body of individuals, scattered throughout the 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. + +## The Core Commitment + +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). + +## The Sustainability Principles + +* The software must be released under a Free and Open Source license. +* Rules for membership in the community 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. +* We must have a strong code of conduct, with clear, fair enforcement mechanisms. +* Any patents included in the software must be granted under the terms of the open source license. +* 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. +* 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 model must bend away from the creation of proprietary downstream software + diff --git a/content/sfosc-book/_index.md b/content/sfosc-book/_index.md new file mode 100644 index 0000000..48c888d --- /dev/null +++ b/content/sfosc-book/_index.md @@ -0,0 +1,25 @@ ++++ +title = "The Book" +date = 2018-11-29T12:13:12-08:00 +weight = 10 +chapter = true ++++ + +# The Sustainable Free and Open Source Communities Book + +### Written by Adam Jacob + +This book is the collection of thoughts and research that resulted in the [principles]({{% ref "principles" %}}), [governance models]({{% ref "governance-models" %}}), [business models]({{% ref "business-models" %}}), and [social contracts]({{% ref "social-contracts" %}}). It walks through how I analyzed the problem of building sustainable open source communities through the lens of John Rawls' Theory of Justice, and pulls from that analysis the items in the principles. + +If you want to contribute to the conversation around Sustainable Free and Open Source Communities, it's the place to begin reading. + +I want to give thanks to the many people who read drafts, bounced around ideas, or were kind enough to let me talk (and talk) about these ideas. They may or may not agree with what I wrote, but they were instrumental in my writing it, and without them it wouldn't exist. + + * Katie Bethell, who was willing to read Rawls to talk about this with me over dinner. + * Jeff Hackert, a true friend. Without his validation and enthusasism, my own imposter syndrome would have stopped me before I started. + * Corey Scobie, an incredible engineering and product mind, who talked the business models through with me over and over, even when I was confusing myself. + * Brad Henrickson, the best accountability buddy possible, and a true friend who reads your stuff on vacation. + * John Gossman, who has given me insightful feedback not only on this, but on every project I've started in the last few years. I'm thankful to know him. + * Katie Long, our lead counsel at Chef, who talked with me about my understandings of patent, copyright, trademark, and more. + * The Magical Microsoft Open Source Round Table, who were kind enough to listen to these ideas when they were just pages in my notebook, and challenge them in a spirited, delightful conversation. + diff --git a/content/sfosc-book/business-models.md b/content/sfosc-book/business-models.md new file mode 100644 index 0000000..e5b584d --- /dev/null +++ b/content/sfosc-book/business-models.md @@ -0,0 +1,86 @@ ++++ +title = "Business Models" +date = 2018-11-29T12:13:12-08:00 +weight = 40 ++++ + +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 60/40 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. + +An 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 softwares 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 softwares 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](https://www.mongodb.com/): 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](https://www.gnu.org/licenses/agpl-3.0.en.html), 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 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](https://commonsclause.com/), 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](https://opencollective.com/webpack), which uses the [Open Collective](https://opencollective.com/) 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](https://www.vim.org/sponsor/), 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](https://iccf-holland.org/). 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 opensource hypervisor, and XenSource was created as a mechanism for users to pay for support. [Over time, XenSource moved to being a loose open core](https://www.brianmadden.com/opinion/A-brief-history-of-Xen-and-XenSource) company - the hypervisor itself remained free, but XenSource built 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, but might not result in a sustainable business strategy, depending on the growth requirements of the business. + +### 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. The 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? + +1. Free software products have trademarked, proprietary distributions, with commercial terms attached. +2. 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 meed 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). + + diff --git a/content/sfosc-book/conception.md b/content/sfosc-book/conception.md new file mode 100644 index 0000000..de1c3f0 --- /dev/null +++ b/content/sfosc-book/conception.md @@ -0,0 +1,24 @@ ++++ +title = "A definition of Sustainable Free and Open Source Communities" +menuTitle = "Definition of SFOSC" +date = 2018-11-29T12:13:12-08:00 +weight = 15 ++++ + +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](https://www.gnu.org/philosophy/free-sw.en.html) and the [Open Source Initiatives Open Source Definition](https://opensource.org/osd). 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 sustainable open source communities: longevity. It must 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. + + diff --git a/content/sfosc-book/contribution_and_distribution.md b/content/sfosc-book/contribution_and_distribution.md new file mode 100644 index 0000000..67b6805 --- /dev/null +++ b/content/sfosc-book/contribution_and_distribution.md @@ -0,0 +1,28 @@ ++++ +title = "Contribution and Distribtion" +date = 2018-11-29T12:13:12-08:00 +weight = 35 ++++ + +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 nations 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. Lets 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 now copyright 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 the 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. + + diff --git a/content/sfosc-book/governance.md b/content/sfosc-book/governance.md new file mode 100644 index 0000000..fbc319b --- /dev/null +++ b/content/sfosc-book/governance.md @@ -0,0 +1,68 @@ ++++ +title = "Governance and Behavior" +date = 2018-11-29T12:13:12-08:00 +weight = 30 ++++ + +Lets start by evaluating how to provide fair equality of opportunity for the direction of the project. I see three common models: + +1. Dictatorships, such as Linux, Python, and Chef. +1. Self organizing with loose consensus, as best seen in the Rust community. +1. 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 rusts own core community value of consensus. A [significant amount of effort](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md) has done 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](https://www.apache.org/foundation/governance/), the [Debian Project](https://www.debian.org/social_contract) and [the OpenStack Foundation](https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/). + +Apache publishes an [organizational chart](https://www.apache.org/foundation/governance/orgchart) 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](http://theapacheway.com) (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](https://www.apache.org/foundation/members.html)". 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](https://www.debian.org/social_contract), which defines their principals, and contains the Debian Free Software Guidelines, which defines what software is considered for distribution; and [The Debian Constitution](https://www.debian.org/devel/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](https://www.debian.org/News/2010/20101019), 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 the applicant has done for the project, have your identity verified, understanding of debian philosophy and procedures validated, and have examples of their work available. Assuming all goes well, the applicant is 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](https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/), 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 coporate 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 Core 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](https://governance.openstack.org/tc/). 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 the bylaws require a 2/3 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 foundations 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 2/3 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 boards 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 and Individual Member. + +Given this analysis, what are the attributes of a sustainable open source communities 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. + diff --git a/content/sfosc-book/institutions.md b/content/sfosc-book/institutions.md new file mode 100644 index 0000000..c774da3 --- /dev/null +++ b/content/sfosc-book/institutions.md @@ -0,0 +1,37 @@ ++++ +title = "Designing a Sustainable Institution" +date = 2018-11-29T12:13:12-08:00 +weight = 20 ++++ + +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 communities 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 okjn 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: + +1. 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. +2. 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 persons 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: access, prestige, 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. + diff --git a/content/sfosc-book/introduction.md b/content/sfosc-book/introduction.md new file mode 100644 index 0000000..2b91e3d --- /dev/null +++ b/content/sfosc-book/introduction.md @@ -0,0 +1,23 @@ ++++ +title = "Introduction" +date = 2018-11-29T12:13:12-08:00 +weight = 5 ++++ + +The free and open source community is in a state of introspection deeper than at any time in its history. We are having conversations around "sustainable business models", the rise of "as a service" behemoths in AWS, Google and Microsoft. Questions about if ethics has a place in our governance and licensing models. We are questioning the basic 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. It required some philosophical background to even participate in it. Today, you can be an active participant in Open Source with no background at all in the philosophy. Open Source is in the water for a generation of software developers. + +At the same time, the number of open source companies has 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 commerce often happens as direct product revenue (selling open source products to customers). It happens indirectly more frequently, when the software is a component enabling the business (using open source to generate revenue). This massive influx of capital, on both sides of the equation, raises interesting questions. Can there even be software at this scale 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 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 the social contract a community agrees to. 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 restatement of my own background and motivations. I want my own bias to be as clear as possible, so they can be challenged as we build on these ideas together. The rest is the explanation of the model and analysis I used to arrive at the Principles. I look forward to refining them with you, and developing clear social contracts based on them. I'm excited to explore how we can build sustainable communities together. + + diff --git a/content/sfosc-book/motivations.md b/content/sfosc-book/motivations.md new file mode 100644 index 0000000..bba7ee8 --- /dev/null +++ b/content/sfosc-book/motivations.md @@ -0,0 +1,43 @@ ++++ +title = "Motivations" +date = 2018-11-29T12:13:12-08:00 +weight = 10 ++++ + +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 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 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 my career, the software communities I was a part of never abandoned 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 if those communities weren't in it - but I know that it would be lesser for their absence. + +I started an open source configuration management project called Chef a decade ago. It grew out of my consulting company into a venture backed startup. It has grown quite large since then - contributors, users, and friends. My business has grown with it. In the realm of venture backed startups, 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'm most proud of the Chef Community. 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 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, which we sell to customers for money. This is the dominant model of using open source in business today. + +We add value on top of Chefs’ 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 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 them, 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. 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 we pay. 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 they don't even 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 a 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, then bought by AWS. It's the nightmare scenario of the people behind the Commons Clause - the fear that AWS would destroy my business, that was 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 previous 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 features not supported; some workflows working, others not. This caused significant demand on AWS to align their service with what we produce. As a result, AWS has now launched my commercial product as a service. We share in the revenue. The original OpsWorks is no longer pushed strongly as a competitor. The Chef Community was the protection we had against the most voracious force the software industry has ever seen. + +My entire life in software is possible because of the incredible communities I have been a part of. 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. From that perspective, it is clear what I should do. I should create more proprietary software, not less. I should stop participating in the community, if it means supporting people who don't pay me. + +The evidence for companies doing better the more closed they are is strong. The revenue (and exits) of open source companies is tracked in the [Commercial Open Source Software Company Index](http://oss.cash/). These are not exact numbers - these are mainly private companies. The trend is clear regardless. The companies who are doing the best in business terms are the most closed. They may have large user bases - but they don't have thriving open source communities. In markets where there is competition between open source companies, the most closed company wins. + +The utility of my open source software is in direct tension with my ability to monetize it. The incentives to create an open source community are that it should be healthy, but not too healthy. In the end, the value of my open source software is as a funnel for my proprietary software. Nothing more. It breaks my heart. + +I want to circle my own square. 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 last decade of my life I am most proud of to be the reason my business is successful, not a reason it is not. + + diff --git a/content/sfosc-book/rawls_for_foss.md b/content/sfosc-book/rawls_for_foss.md new file mode 100644 index 0000000..6b4ec89 --- /dev/null +++ b/content/sfosc-book/rawls_for_foss.md @@ -0,0 +1,45 @@ ++++ +title = "Setting up Rawls' Game" +date = 2018-11-29T12:13:12-08:00 +weight = 25 ++++ + +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](https://www.gnu.org/philosophy/free-sw.en.html) (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 communities 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 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. Either for their own benefit or the benefit of their employer. +* *Contributors*: those who engage in the work of making the software better by not by writing code. They might file bug reports, compile release notes, write documentation, answer questions, etc. +* *Evangelists*: people who benefit by raising their own profile by telling others about the benefits of the software. +* *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 provides 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 an As-A-Service Business, but provides the software as a service at the location of the consumers choice. Manages the lifecycle of the software on behalf of the consumer. +* *Consulting Businesses*: sells 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 aren't can't be sure we're evaluating our rules against a realistic field. + diff --git a/content/sfosc-book/the_way_forward.md b/content/sfosc-book/the_way_forward.md new file mode 100644 index 0000000..3c9f42c --- /dev/null +++ b/content/sfosc-book/the_way_forward.md @@ -0,0 +1,13 @@ ++++ +title = "The Way Forward" +date = 2018-11-29T12:13:12-08:00 +weight = 45 ++++ + +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 intentionalally 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]({{% ref "principles" %}}), [business models]({{% ref "business-models" %}}) diff --git a/content/social-contracts/_index.md b/content/social-contracts/_index.md new file mode 100644 index 0000000..3e96a2a --- /dev/null +++ b/content/social-contracts/_index.md @@ -0,0 +1,13 @@ ++++ +title = "Social Contracts" +date = 2018-11-29T12:12:57-08:00 +weight = 5 +chapter = true +pre = "X. " ++++ + +### Chapter X + +# Some Chapter title + +Lorem Ipsum. \ No newline at end of file diff --git a/content/social-contracts/donation.md b/content/social-contracts/donation.md new file mode 100644 index 0000000..b72e016 --- /dev/null +++ b/content/social-contracts/donation.md @@ -0,0 +1,134 @@ +--- +title: "Donation based Social Contract" +layout: "contract" +menuTitle: "Donation" +date: 2018-11-29T12:13:32-08:00 +--- + +## 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](https://sfosc.github.io/principles). + +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 avialable 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 + +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. + +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. + +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 +exeception is ammending this social contract. This can only be done with a 3/4 +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 is directly sustained through a donation model. Donations +should can be made through [DONATION SYSTEM]. Further details can be +found in the [DONATION POLICY]. + diff --git a/layouts/contract.html b/layouts/contract.html new file mode 100644 index 0000000..22797e6 --- /dev/null +++ b/layouts/contract.html @@ -0,0 +1,15 @@ +{{ partial "header.html" . }} + +{{ readFile "contracts_parts/principles.md" | markdownify }} + +{{ .Content }} + + + +{{ partial "footer.html" . }} + diff --git a/layouts/contract_parts/principles.md b/layouts/contract_parts/principles.md new file mode 100644 index 0000000..61f2570 --- /dev/null +++ b/layouts/contract_parts/principles.md @@ -0,0 +1,29 @@ +## Preamble + +We are a unified body of individuals, scattered throughout the 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. + +## The Core Commitment + +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). + +## The Sustainability Principles + +* The software must be released under a Free and Open Source license. +* Rules for membership in the community 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. +* We must have a strong code of conduct, with clear, fair enforcement mechanisms. +* Any patents included in the software must be granted under the terms of the open source license. +* 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. +* 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 model must bend away from the creation of proprietary downstream software + diff --git a/layouts/partials/logo.html b/layouts/partials/logo.html new file mode 100644 index 0000000..6ec52bb --- /dev/null +++ b/layouts/partials/logo.html @@ -0,0 +1 @@ +

 SFOSC

diff --git a/layouts/partials/principles.html b/layouts/partials/principles.html new file mode 100644 index 0000000..61f2570 --- /dev/null +++ b/layouts/partials/principles.html @@ -0,0 +1,29 @@ +## Preamble + +We are a unified body of individuals, scattered throughout the 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. + +## The Core Commitment + +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). + +## The Sustainability Principles + +* The software must be released under a Free and Open Source license. +* Rules for membership in the community 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. +* We must have a strong code of conduct, with clear, fair enforcement mechanisms. +* Any patents included in the software must be granted under the terms of the open source license. +* 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. +* 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 model must bend away from the creation of proprietary downstream software + diff --git a/themes/hugo-theme-learn b/themes/hugo-theme-learn new file mode 160000 index 0000000..9ed9958 --- /dev/null +++ b/themes/hugo-theme-learn @@ -0,0 +1 @@ +Subproject commit 9ed9958316b419d9820dae850d93dfc762b79e4b