index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>SFOSC on </title>
    <link>/</link>
    <description>Recent content in SFOSC on </description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Thu, 29 Nov 2018 11:01:38 -0800</lastBuildDate>
    
	<atom:link href="/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>None</title>
      <link>/business-models/none/</link>
      <pubDate>Wed, 09 Jan 2019 00:00:00 +0000</pubDate>
      
      <guid>/business-models/none/</guid>
      <description>This is a common archetype for Sustainable Free and Open Source Communities. The business model is to not have a business model. That is okay, because not every sustainable open source project needs or wants a business model.
In this case the project has set up means and rules of collaboration, has a formal membership, usually without a formal position of authority or any other hierarchy and does not deal with monetary contributions.</description>
    </item>
    
    <item>
      <title>Code of Conduct</title>
      <link>/about/code_of_conduct/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/code_of_conduct/</guid>
      <description>Contributor Covenant Code of Conduct Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
Our Standards Examples of behavior that contributes to creating a positive environment include:</description>
    </item>
    
    <item>
      <title>Contributing</title>
      <link>/about/contributing/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/contributing/</guid>
      <description>Request for Contributions We would love to have you help us evolve the principles, write new social contracts, and further explore what it means to create sustainable free and open source communities.
In particular, we seek the following types of contributions:
 ideas: participate in an issues thread or start your own to voice your idea copy editing: contribute your expertise by helping us expand, clarify and proofing our content code: improve the design, usability and functionality of the sfosc page artwork: contribute graphics or any other artwork improving the presentation of sfosc  Read this guide on how to do that.</description>
    </item>
    
    <item>
      <title>Membership</title>
      <link>/about/membership/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/membership/</guid>
      <description>Membership in the SFOSC Welcome! Anyone who is interested in contributing to the SFOSC in any way is welcome to become a member.
Membership is not a requirement for participating in the community. Members may be consulted about governance of the community. For example through votes. The CONTRIBUTING GUIDELINES explain several ways you can contribute regardless of membership.
Membership in the community is broad based, available to anyone who is participating in any fashion.</description>
    </item>
    
    <item>
      <title>Social Contract</title>
      <link>/about/social_contract/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/social_contract/</guid>
      <description>Introduction This document describe the social contract for the community around a piece of open source software (&amp;ldquo;the software&amp;rdquo;). 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.</description>
    </item>
    
    <item>
      <title>Trademark</title>
      <link>/about/trademark/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/trademark/</guid>
      <description>Trademark Policy The Sustainable Free and Open Source Community, and the SFOSC, are not currently trademarked. We do ask that, if you want to republish this content, you do so in line with the terms of our license. </description>
    </item>
    
    <item>
      <title>Voting</title>
      <link>/about/voting/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/about/voting/</guid>
      <description>Voting Guidelines Every member in the MEMBERSHIP file is allowed one vote. We will use Helios to organize the actual vote, and certify the results. </description>
    </item>
    
    <item>
      <title>Free Software Island</title>
      <link>/business-models/free-software-island/</link>
      <pubDate>Thu, 06 Dec 2018 11:29:21 -0800</pubDate>
      
      <guid>/business-models/free-software-island/</guid>
      <description>A Free Software Island is a project, usually enabled by a foundation, where everyone agrees the software is created purely for the public good. Individuals and businesses alike agree to co-operate with each other on the software that is contained on the island, for mutual benefit.
Who uses it?  All of the software developed by the Apache Foundation All of the software developed by the CNCF All of the software developed by the OpenStack Foundation  Projects like Envoy were free software islands even before they joined a foundation (the CNCF in this case).</description>
    </item>
    
    <item>
      <title>Introduction</title>
      <link>/sfosc-book/introduction/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/introduction/</guid>
      <description>The free and open source community is in a deeper state of introspection than at any time in its history. We are thinking through and having conversations about &amp;ldquo;sustainable business models&amp;rdquo; and the rise of &amp;ldquo;as a service&amp;rdquo; behemoths in AWS, Google and Microsoft. We are asking ourselves if ethics have a place in our governance and licensing models. We are questioning the fundamental values and ideas of the movement itself.</description>
    </item>
    
    <item>
      <title>Loose Open Core</title>
      <link>/business-models/loose-open-core/</link>
      <pubDate>Thu, 06 Dec 2018 11:45:36 -0800</pubDate>
      
      <guid>/business-models/loose-open-core/</guid>
      <description>Loose Open Core is a model where the software has its primary functionality covered under an open source license (the &amp;ldquo;core&amp;rdquo;), with proprietary software wrapped around it. This model encourages widespread distribution of the core software, and tries to ensure that enough value exists in the proprietary software around it to convince their target market to make a purchase.
Who uses it?  Chef Software Puppet Hashicorp  When should it be used?</description>
    </item>
    
    <item>
      <title>Motivations</title>
      <link>/sfosc-book/motivations/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/motivations/</guid>
      <description>For my own part, I started my journey with Free Software in 1994, with a copy of Slackware I installed from floppies. I had been running a Bulletin board system (BBS) for years, and I had become an operating system nerd because I wanted true multi-tasking. I was so proud of running a copy of OS/2 Warp. Slackware changed everything for me - I could see the source code, read the man pages.</description>
    </item>
    
    <item>
      <title>Tight Open Core</title>
      <link>/business-models/tight-open-core/</link>
      <pubDate>Thu, 06 Dec 2018 12:01:01 -0800</pubDate>
      
      <guid>/business-models/tight-open-core/</guid>
      <description>Tight Open Core is a model where the software has its primary functionality covered under an open source license (the &amp;ldquo;core&amp;rdquo;), but has direct (often critical) features that are only available under a proprietary license.
Take, for example, the feature of authentication and authorization. Some amount of these are critical for almost all software. In a Tight Open Core model, this functionality will not exist in the open source core: instead, it will be pushed to either proprietary plugins or exist only in fully proprietary builds.</description>
    </item>
    
    <item>
      <title>A definition of Sustainable Free and Open Source Communities</title>
      <link>/sfosc-book/conception/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/conception/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>Dual Licensing</title>
      <link>/business-models/dual-licensing/</link>
      <pubDate>Thu, 06 Dec 2018 12:15:31 -0800</pubDate>
      
      <guid>/business-models/dual-licensing/</guid>
      <description>Dual Licensing is a model where the software is released under an open source license, almost always a copyleft license, but has a single entity with full control of the software&amp;rsquo;s copyright. This enables the company to re-license the software as they see fit - either to sell it under a non-copyleft license, to run it as a service, or to sell proprietary versions, while restricting the rights of others to do the same.</description>
    </item>
    
    <item>
      <title>Designing a Sustainable Institution</title>
      <link>/sfosc-book/institutions/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/institutions/</guid>
      <description>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&amp;rsquo;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.</description>
    </item>
    
    <item>
      <title>As a Service</title>
      <link>/business-models/as-a-service/</link>
      <pubDate>Thu, 06 Dec 2018 12:27:40 -0800</pubDate>
      
      <guid>/business-models/as-a-service/</guid>
      <description>The As a Service model is when the software is released under an open source license, and available for anyone to run, while also being made available As a Service by the company.
Who Uses it?  Discourse MongoDB WordPress  When should it be used? When the software is primarily consumer oriented, or has a large operational overhead. The goal here is that the software has the simplest on-ramp possible, and requires no effort to maintain over time.</description>
    </item>
    
    <item>
      <title>Setting up Rawls&#39; Game</title>
      <link>/sfosc-book/rawls_for_foss/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/rawls_for_foss/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>Donations</title>
      <link>/business-models/donations/</link>
      <pubDate>Thu, 06 Dec 2018 12:49:15 -0800</pubDate>
      
      <guid>/business-models/donations/</guid>
      <description>Not really a &amp;ldquo;business model&amp;rdquo;, but let&amp;rsquo;s go with it anyway. The donations model is when the project sets up a system of donations, which are used to sustain the project.
Who uses it?  Vim Webpack  When should it be used? When the project is core infrastructure, primarily run by volunteers, or simply to do good in the world.
What kind of monetization is possible? Anything that is valid under the license.</description>
    </item>
    
    <item>
      <title>Governance and Behavior</title>
      <link>/sfosc-book/governance/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/governance/</guid>
      <description>Lets start by evaluating how to provide fair equality of opportunity for the direction of the project. I see three common models:
 Dictatorships, such as Linux, Python (before the resignation of Guido van Rossum and the adoption of a steering council model), and Chef. Self organizing with loose consensus, as best seen in the Rust community. Democracies, represented by the Apache Foundation, The Debian Project, and OpenStack.  How does each stack up to Rawls&amp;rsquo; principles?</description>
    </item>
    
    <item>
      <title>Support</title>
      <link>/business-models/support/</link>
      <pubDate>Thu, 06 Dec 2018 14:37:03 -0800</pubDate>
      
      <guid>/business-models/support/</guid>
      <description>The Support model is one where the software is available under an open source license, but in order to have the company available to answer questions, assist in implementation, etc., you must purchase a support contract.
This model is often confused for the Free Software Product model.
Who Uses it?  XenSource (very early on - moved to loose open core over time) Ntop Zabbix MySQL  When should it be used?</description>
    </item>
    
    <item>
      <title>Contribution and Distribution</title>
      <link>/sfosc-book/contribution_and_distribution/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/contribution_and_distribution/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>Free Software Product</title>
      <link>/business-models/free-software-product/</link>
      <pubDate>Thu, 06 Dec 2018 14:48:18 -0800</pubDate>
      
      <guid>/business-models/free-software-product/</guid>
      <description>The Free Software Product model has 100% of the software covered by an open source license, but distributes the software as a complete, supported product under a proprietary license.
Free Software Product companies use their trademark rights, along with the license of the software itself, to create proprietary derivatives. If there is a 100% open source distribution, it uses different trademarks and naming conventions, and receives little or no direct support for users from the upstream.</description>
    </item>
    
    <item>
      <title>Business Models</title>
      <link>/sfosc-book/business-models/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/business-models/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>The Way Forward</title>
      <link>/sfosc-book/the_way_forward/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:12 -0800</pubDate>
      
      <guid>/sfosc-book/the_way_forward/</guid>
      <description>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&amp;rsquo; intentions, their relationship to monetization, and the principles upon which they will thrive: their community social contract.</description>
    </item>
    
    <item>
      <title>Donation based Social Contract</title>
      <link>/social-contracts/donation/</link>
      <pubDate>Thu, 29 Nov 2018 12:13:32 -0800</pubDate>
      
      <guid>/social-contracts/donation/</guid>
      <description>Introduction This document describes the social contract for the community around a piece of open source software (&amp;ldquo;the software&amp;rdquo;). 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.</description>
    </item>
    
  </channel>
</rss>