Full Code of nayafia/lemonade-stand for AI

master 2af127faa3f6 cached
2 files
33.9 KB
8.1k tokens
1 requests
Download .txt
Repository: nayafia/lemonade-stand
Branch: master
Commit: 2af127faa3f6
Files: 2
Total size: 33.9 KB

Directory structure:
gitextract_d2g6j7_9/

├── LICENSE
└── README.md

================================================
FILE CONTENTS
================================================

================================================
FILE: LICENSE
================================================
CC0 1.0 Universal

Statement of Purpose

The laws of most jurisdictions throughout the world automatically confer
exclusive Copyright and Related Rights (defined below) upon the creator and
subsequent owner(s) (each and all, an "owner") of an original work of
authorship and/or a database (each, a "Work").

Certain owners wish to permanently relinquish those rights to a Work for the
purpose of contributing to a commons of creative, cultural and scientific
works ("Commons") that the public can reliably and without fear of later
claims of infringement build upon, modify, incorporate in other works, reuse
and redistribute as freely as possible in any form whatsoever and for any
purposes, including without limitation commercial purposes. These owners may
contribute to the Commons to promote the ideal of a free culture and the
further production of creative, cultural and scientific works, or to gain
reputation or greater distribution for their Work in part through the use and
efforts of others.

For these and/or other purposes and motivations, and without any expectation
of additional consideration or compensation, the person associating CC0 with a
Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
and publicly distribute the Work under its terms, with knowledge of his or her
Copyright and Related Rights in the Work and the meaning and intended legal
effect of CC0 on those rights.

1. Copyright and Related Rights. A Work made available under CC0 may be
protected by copyright and related or neighboring rights ("Copyright and
Related Rights"). Copyright and Related Rights include, but are not limited
to, the following:

  i. the right to reproduce, adapt, distribute, perform, display, communicate,
  and translate a Work;

  ii. moral rights retained by the original author(s) and/or performer(s);

  iii. publicity and privacy rights pertaining to a person's image or likeness
  depicted in a Work;

  iv. rights protecting against unfair competition in regards to a Work,
  subject to the limitations in paragraph 4(a), below;

  v. rights protecting the extraction, dissemination, use and reuse of data in
  a Work;

  vi. database rights (such as those arising under Directive 96/9/EC of the
  European Parliament and of the Council of 11 March 1996 on the legal
  protection of databases, and under any national implementation thereof,
  including any amended or successor version of such directive); and

  vii. other similar, equivalent or corresponding rights throughout the world
  based on applicable law or treaty, and any national implementations thereof.

2. Waiver. To the greatest extent permitted by, but not in contravention of,
applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
and Related Rights and associated claims and causes of action, whether now
known or unknown (including existing as well as future claims and causes of
action), in the Work (i) in all territories worldwide, (ii) for the maximum
duration provided by applicable law or treaty (including future time
extensions), (iii) in any current or future medium and for any number of
copies, and (iv) for any purpose whatsoever, including without limitation
commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
the Waiver for the benefit of each member of the public at large and to the
detriment of Affirmer's heirs and successors, fully intending that such Waiver
shall not be subject to revocation, rescission, cancellation, termination, or
any other legal or equitable action to disrupt the quiet enjoyment of the Work
by the public as contemplated by Affirmer's express Statement of Purpose.

3. Public License Fallback. Should any part of the Waiver for any reason be
judged legally invalid or ineffective under applicable law, then the Waiver
shall be preserved to the maximum extent permitted taking into account
Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
is so judged Affirmer hereby grants to each affected person a royalty-free,
non transferable, non sublicensable, non exclusive, irrevocable and
unconditional license to exercise Affirmer's Copyright and Related Rights in
the Work (i) in all territories worldwide, (ii) for the maximum duration
provided by applicable law or treaty (including future time extensions), (iii)
in any current or future medium and for any number of copies, and (iv) for any
purpose whatsoever, including without limitation commercial, advertising or
promotional purposes (the "License"). The License shall be deemed effective as
of the date CC0 was applied by Affirmer to the Work. Should any part of the
License for any reason be judged legally invalid or ineffective under
applicable law, such partial invalidity or ineffectiveness shall not
invalidate the remainder of the License, and in such case Affirmer hereby
affirms that he or she will not (i) exercise any of his or her remaining
Copyright and Related Rights in the Work or (ii) assert any associated claims
and causes of action with respect to the Work, in either case contrary to
Affirmer's express Statement of Purpose.

4. Limitations and Disclaimers.

  a. No trademark or patent rights held by Affirmer are waived, abandoned,
  surrendered, licensed or otherwise affected by this document.

  b. Affirmer offers the Work as-is and makes no representations or warranties
  of any kind concerning the Work, express, implied, statutory or otherwise,
  including without limitation warranties of title, merchantability, fitness
  for a particular purpose, non infringement, or the absence of latent or
  other defects, accuracy, or the present or absence of errors, whether or not
  discoverable, all to the greatest extent permissible under applicable law.

  c. Affirmer disclaims responsibility for clearing rights of other persons
  that may apply to the Work or any use thereof, including without limitation
  any person's Copyright and Related Rights in the Work. Further, Affirmer
  disclaims responsibility for obtaining any necessary consents, permissions
  or other rights required for any use of the Work.

  d. Affirmer understands and acknowledges that Creative Commons is not a
  party to this document and has no duty or obligation with respect to this
  CC0 or use of the Work.

For more information, please see
<http://creativecommons.org/publicdomain/zero/1.0/>


================================================
FILE: README.md
================================================
# A handy guide to financial support for open source.
*"I do open source work, how do I find funding?"*

This document aims to provide an exhaustive list of all the ways that people get paid for open source work. Hopefully, projects and contributors will find this helpful in figuring out the best options for them.

The list below is roughly ordered from small to large. Each funding category links to several real examples (using topical articles or pages wherever possible instead of just a project's homepage.)

The categories are not mutually exclusive. For example, a project might have a foundation but also use crowdfunding to raise money. Someone else might do consulting and also have a donation button. Etc. 


---


# Table of Contents
1. [Donation button](#donation-button)
2. [Bounties](#bounties)
3. [Sponsorware](#sponsorware)
4. [Crowdfunding (one-time)](#crowdfunding-one-time)
5. [Crowdfunding (recurring)](#crowdfunding-recurring)
6. [Books and merchandise](#books-and-merchandise)
7. [Advertising & sponsorships](#advertising--sponsorships)
8. [Get hired by a company to work on project](#get-hired-by-a-company-to-work-on-project)
9. [Start a project while currently employed](#start-a-project-while-currently-employed)
10. [Grants](#grants)
11. [Consulting](#consulting)
12. [Paid support](#paid-support)
13. [SaaS](#saas)
14. [Copyleft + paid license](#copyleft--paid-license)
15. [Open core](#open-core)
16. [Foundations & consortiums](#foundations--consortiums)
17. [Venture capital](#venture-capital)
18. [Restricted license](#restricted-license)

APPENDIX: [Contributing to this guide](#contributing-to-this-guide) // [License & attribution](#license-and-attribution)  
TRANSLATIONS: [Traditional Chinese(繁體中文)](https://github.com/jserv/lemonade-stand) // [Simplified Chinese(簡體中文)](https://github.com/wizicer/FinancialSupportForOpenSource) // [Italian(italiano)](https://github.com/dakk/lemonade-stand) // [Japanese(日本語)](https://github.com/fumikito/lemonade-stand) // [Russian(русский)](https://github.com/saviorand/lemonade-stand_ru) // [Bulgarian(български)](https://github.com/BlueButterflies/HowToPaidFromOpenSource-/tree/main)

**"personal effort" notes when a funding effort was led by an individual, not a project*

## Donation button

*Stick a donation button on your site. Stripe and PayPal are examples of services you can use to accept donations.*

#### Pros

* Few strings attached
* Little work involved: "set it and forget it"

#### Cons

* Usually not much money unless you have dedicated fundraising efforts
* Need an entity to accept donations, which may take a fee for doing so.  Examples are Stripe and PayPal.
* To make donations tax-free for the person/organization who is donating, may need a legally charitable entity (in the United States, a 501(c)(3) nonprofit entity) to accept donations. [Software Freedom Conservancy](https://sfconservancy.org) and [NumFOCUS](https://www.numfocus.org) are examples. Harder for individuals or international donations to manage
* Sometimes not clear who “deserves” money in a project or how it gets distributed. An entity like [OpenCollective](http://opencollective.com) may help with this.

#### Case Studies

* [ChatSecure](https://chatsecure.org/blog/sustainable-open-source-starts-with-you/)
* [Git](https://git-scm.com/sfc)
* [Transmission](https://www.transmissionbt.com/)
* [Twisted](https://twistedmatrix.com/trac/wiki/WhyDonate)

## Bounties

*Sometimes, projects or companies post bounties for open source work (ex. "fix this bug and collect $100"). There are several websites, listed below, that help facilitate the posting and collection of bounties.*

#### Pros

* Open to community participation
* Money is tied to doing specific work (more like paying for service than donations)
* Especially popular for security work

#### Cons

* Can create perverse incentives in a project (low quality PRs, distracting priorities)
* Conflicts can arise over whether work fulfills a bounty
* Usually not much money per bounty (~<$500)
* Doesn’t provide recurring revenue

#### Case Studies

* [Gitcoin](https://gitcoin.co/explorer)
* [GitHub Bug Bounty Program](https://bounty.github.com/)
* [Google Patch Rewards](https://www.google.com/about/appsecurity/patch-rewards/)
* [Inkscape's "funded development" system](https://inkscape.org/support-us/funded-development/)
* [Internet Bug Bounty](https://internetbugbounty.org/)
* [IssueHunt](https://issuehunt.io)

## Sponsorware

*If you'd like to open source a project but want to ensure that others will invest in its long-term maintenance, you could tell your community that you'll open source the project once you've hit a certain amount of sponsorship. (Writer Tim Carmody refers to this as ["unlocking the commons."](https://www.niemanlab.org/2019/01/unlocking-the-commons/))*

*This is similar to [Crowdfunding (one-time)]((#crowdfunding-one-time)) described below, except that instead of funding the work in advance, you build the software from the get-go, then choose whether or not to open source it depending on whether you hit your goal.*

#### Pros

* Can be a recurring source of revenue after initial development, depending on how you set up the conditions of releasing the project
* It can be a useful signal as to whether people value the package
* Gives people immediate value – people can sponsor you and get access to the package right away
* Doesn’t restrict future potential growth of the project and upholds the spirit of open source

#### Cons

* Doesn't work for projects that are already released
* Likely only works for eye-catching projects where a demo or proof-of-concept is very exciting

#### Case Studies

* [Caleb Porzio's `sushi` package](https://calebporzio.com/sponsorware)

## Crowdfunding (one-time)

*If you have a specific idea you'd like to implement (rather than ongoing project work), a one-time crowdfunding campaign can help raise the funds you need. Both individuals and companies might be willing to donate to your campaign.*

#### Pros

* Few strings attached
* Can be easier for an individual to legally manage via, e.g. [Kickstarter](https://kickstarter.com/)

#### Cons

* Lots of work involved to market campaign
* Usually has to be tied to concrete outcome, perks
* Usually not that much money (~$50K for one time)
* Companies are not always comfortable donating to campaigns

#### Case Studies

* [Andrew Godwin + Django (personal effort)](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)
* [Dave Gandy + Font Awesome](https://www.kickstarter.com/projects/232193852/font-awesome-5)
* [GDAL Coordinate System Barn Raising](https://gdalbarn.com/)
* [Monero Community Crowdfunding System (CCS)](https://ccs.getmonero.org/)
* [RESTful WP-CLI](https://poststatus.com/kickstarter-open-source-project/)

## Crowdfunding (recurring)

*If you'd like to fund ongoing project work, you can set up a recurring crowdfunding campaign, with a monthly or annual financial commitment that renews indefinitely (or until the donor cancels). Those who use your project regularly (including both individuals and companies) might be willing to fund your work.*

#### Pros

* Few strings attached
* Can be easier for an individual to legally manage via, e.g. [Patreon](https://patreon.com), [Liberapay](https://liberapay.com/), [OpenCollective](https://opencollective.com)

#### Cons

* Harder to get commitments to recurring donations (often requires preexisting brand/reputation)
* Harder to explain concrete outcomes, perks that come with recurring donations
* Usually not that much money (~$1-4K monthly)
* Companies are not always comfortable donating to campaigns

#### Case Studies

* [Babel](https://opencollective.com/babel)
* [Caleb Porzio + Laravel Livewire and more](https://calebporzio.com/i-just-hit-dollar-100000yr-on-github-sponsors-heres-how-i-did-it)
* [Clojurists Together](https://clojuriststogether.org)
* [Eran Hammer + hapi Patreon](https://www.patreon.com/eranhammer)
* [ESLint](https://eslint.org/blog/2019/02/funding-eslint-future)
* [Evan You + Vue.js Patreon](https://www.patreon.com/evanyou)
* [GnuPG](https://www.gnupg.org/donate/index.html)
* [Ruby Together](https://rubytogether.org)
* [Tom Christie + Django REST framework (personal effort)](https://fund.django-rest-framework.org/topics/funding/)
* [webpack](https://opencollective.com/webpack)

## Books and merchandise

*If you are an expert in a domain that other people might find useful to learn about, you could write and sell a book or series of books. You can find a publisher (like O'Reilly) or self-publish. In addition to selling books, some projects sell merchandise (ex. shirts, hoodies) to support their work.*

#### Pros

* Outcome not tied to project work itself, so you retain creative freedom
* Can serve as marketing for the project itself
* Can be recurring source of revenue after initial development

#### Cons

* Often not a significant source of revenue
* Can distract from the core development of a project
* Merchandise can have upfront costs

#### Case Studies

* [CocoaPods (fundraising for charity)](https://cocoapods.org/socks)
* [Daniel and Audrey Roy Greenfeld + Two Scoops of Django (personal effort)](https://www.twoscoopspress.com/products/two-scoops-of-django-1-8)
* [Kyle Simpson + You Don't Know JS (personal effort)](https://github.com/getify/You-Dont-Know-JS)
* [Lua](https://www.lua.org/pil/)
* [Sandi Metz + Practical Object-Oriented Design in Ruby (personal effort)](http://www.poodr.com/)

## Advertising & sponsorships

*If your project has a large audience, you can sell sponsorships to advertisers who might want to reach them. You probably have a very targeted audience (ex. if you have a Python project, you can assume your audience is likely people who are technically familiar with Python), so use that to your advantage.*

#### Pros

* Business model aligned with something people are willing to pay for

#### Cons

* Need a large enough audience to justify sponsorships
* Need to manage trust and transparency with user base (ex. no tracking)
* Can be a lot of work to find and manage clients
* Can involve ethical concerns about marketing
* Can introduce a conflict of interest; making controversial changes could result in losing sponsors/advertisers 

#### Case Studies

* [CodeFund](https://codefund.io)
* [GitFund](https://gitfund.io)
* [Hoodie](http://hood.ie/sponsoring/)
* [Read the Docs](http://blog.readthedocs.com/ads-on-read-the-docs/)
* [Feross's experiment with StandardJS](https://feross.org/funding-experiment-recap/)
* Kite sponsorship of Minimap ([summary](https://medium.com/@nayafia/the-kite-debacle-is-democracy-at-work-6a04bc043c50))
* [Caddy](https://github.com/caddyserver/caddy) (exclusively sponsorships)

## Get hired by a company to work on a project

*Companies sometimes hire individuals to do open source work. Find a company that uses the project you want to work on. Often this is a split arrangement (ex. 50% company work, 50% open source work). Alternatively, if you have an idea for a new project, find a company that would be interested in using what you produce. In these situations, having demonstrated experience you can point to will be very helpful.*

#### Pros

* Taps into those who have resources (i.e. companies)
* Can be well-aligned with company needs
* Steady income

#### Cons

* Usually involves “getting lucky”: no clear, repeatable path to finding this arrangement
* Project already needs to be well-known and used
* Person not contributing to company’s bottom line, which makes them expendable
* Governance issues, a company could have undue influence over the project
* Can affect project dynamics + balance

#### Case Studies

* [Aaron Patterson + ManageIQ and Ruby, Rails (personal effort)](http://community.redhat.com/blog/2014/09/tenderlove-joins-manageiq/)
* [Donald Stufft + Hewlett-Packard and Python packaging (personal effort)](https://twitter.com/dstufft/status/594119386333609984)
* [Rich Hickey + Cognitect and Clojure](http://www.bizjournals.com/triangle/news/2013/09/17/durhams-relevance-to-merge-with.html?full=true)
* [Ryan Dahl + Joyent and Node.js (opens a YouTube video) (personal effort)](http://www.youtube.com/watch?v=SAc0vQCC6UQ&t=29m20s)

## Start a project while currently employed

*Many open source projects started as employee side projects. The project might eventually outgrow the company, but starting it as a side project can be a great way to incubate the idea.*

*If you pursue this path, make sure you understand your company's policy on open source work. Some companies encourage employees to contribute to open source during working hours. Some might treat your open source work as a company project. Don't assume anything; ask someone at your company before starting.*

#### Pros

* Freedom to test new ideas without worrying about salary
* Can be well-aligned with company needs
* Suitable for newer, experimental ideas

#### Cons

* Need to do it as a side project or be approved to work on it during salaried time
* Risk of undue company influence
* Can lead to complicated governance later down the line

#### Case Studies

* [Facebook and React](https://www.quora.com/How-was-the-idea-to-develop-React-conceived-and-how-many-people-worked-on-developing-it-and-implementing-it-at-Facebook/answer/Bill-Fisher-17)
* [Futurice's open source program](http://futurice.com/blog/sponsoring-free-time-open-source-activities)
* [Google and Go](https://golang.org/doc/faq#history)
* [Mozilla and Rust](https://prev.rust-lang.org/en-US/faq.html#is-this-project-controlled-by-mozilla)
* [Formidable's Sauce program](https://formidable.com/blog/2019/sauce-program/), where they pay employees for their open source contributions


## Grants

*Grants are monetary gifts that do not require repayment. Oftentimes the grantmaker receives other benefits from giving you the grant, such as access to you, demonstration of impact, a report of your work, or tax benefits.*

*Grants can come from many places, including companies, software foundations, philanthropic foundations, and the government. The technical and legal aspects of a grant vary greatly depending on where it comes from. For example, a company might give you a "grant" but legally treat it as a consulting invoice. A philanthropic foundation can only make grants to nonprofits, so you would need to be a nonprofit yourself, or (more commonly) find a nonprofit to sponsor you. If you're unfamiliar with grants, the best way to understand how grants work is to talk to someone who has received one before. Some examples of grant recipients are listed below.*

#### Pros

* Fewer strings attached
* Guaranteed money can help project focus for an unbroken period of time
* Gives project room to breathe and experiment

#### Cons

* There aren’t many software-related grantmakers (philanthropic, gov’t, corporate)
* Grants are finite. Still need to find sustainability beyond the life of a grant

#### Case Studies

* [Andrey Petrov + Stripe Open-Source Retreat and urllib3](https://medium.com/@shazow/urllib3-stripe-and-open-source-grants-edb9c0e46e82#.45ylnxrh4)
* [Chan-Zuckerberg Initiative grant program for open source software in science](https://chanzuckerberg.com/rfa/essential-open-source-software-for-science/)
* [Dash Budget Proposal Tracker](https://dashvotetracker.com/)
* [Dat Project](https://blog.datproject.org/2017/09/15/dat-funding-history/)
* [Django + Mozilla Open Source Support](https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/)
* [FLOSS/Fund](https://floss.fund/)
* [GitHub Secure Open Source Fund](https://resources.github.com/github-secure-open-source-fund/)
* [Grin General Fund](http://grin-tech.org/funding.html)
* [Handshake community grant program](https://handshake.org)
* [Libraries.io grant applications](https://github.com/librariesio/supporters)
* [ralphtheninja/open-funding](https://github.com/ralphtheninja/open-funding#grants) has a list of grants
* [Segment Open Fellowship](https://segment.com/blog/segment-open-fellowship-2017/)
* [Sentry Open Source Grant](https://blog.sentry.io/2019/01/29/apply-sentry-open-source-grant)

## Consulting

*Consulting can be a flexible way to fund open source work. You have more freedom to structure your time as you wish (for example, consulting 30 hrs of the week and spending 10 hrs of the week on open source work). Consultants can usually charge more for their time than salaried employees because the work is less steady, they don't receive benefits, etc. If you plan on doing this type of work regularly, you will probably want to set up an LLC (or equivalent outside of the US).*

*If your project is popular, you can also offer consulting & services around the project itself. For example, a client might pay you to implement the project for them, build something custom, or train them on how to use it.*

#### Pros

* Business model aligned with something people are willing to pay for

#### Cons

* Consulting requires human power, doesn’t scale well (except for rare outliers)
* Business needs can distract from writing code or other tasks related to the project itself
* Can be at odds with making software simple to use
* Project needs to be sufficiently popular that people are willing to pay for related services

#### Case Studies

* [Baroque Software](http://baroquesoftware.com/)
* [Neighbourhoodie](https://neighbourhood.ie/)
* [OpenSSL Software Foundation](https://www.openssl.org/community/contacts.html) formerly [OpenSSL Software Services](https://web.archive.org/web/20180817114118/opensslservices.com/what.html)
* [Varnish Moral License](http://phk.freebsd.dk/VML/)

## Paid support

*In this model, the code is freely available, but users need to pay to receive support from the project's maintainers. That might mean charging for access to the issue tracker, office hours, a community Slack, or an SLA (service-level agreement).*

#### Pros

* Business model aligned with something people are willing to pay for

#### Cons

* Can be at odds with making software simple to use
* Project needs to be sufficiently popular that people are willing to pay
* Maintainers don't necessarily want to offer professional support

#### Case Studies

* [Fody](https://github.com/Fody/Fody/blob/master/readme.md): Must be a Patreon supporter to open an issue or pull request
* [Prism](https://www.patreon.com/prismlibrary): Supporting their Patreon gives you access to their community Slack channel for project support
* [Red Hat](https://en.wikipedia.org/wiki/Red_Hat#Business_model)
* [Tidelift paid subscriptions](https://tidelift.com/subscription)

## SaaS

*SaaS means [Software as a Service](https://en.wikipedia.org/wiki/Software_as_a_service). In this model, the codebase itself can remain open source, but you offer paid services such as charging for use of a main hosted site or for handling the hosting of dedicated instances for customers. Typically, paying customers also get priority support.*

#### Pros

* Can build community around open project and make money off of services for hosting
* Allows open source project to focus on users, and as needs grow to help enterprises adopt the project
* Can scale by number of users

#### Cons

* Often means the hosting needs to be cheaper than hiring a dev to run the project for you.
* “Two tiers” of product support can make free users unhappy

#### Case Studies

* [Discourse](https://www.discourse.org/)
* [Forge Laravel](https://forge.laravel.com/)
* [Ghost](https://ghost.org/about/)
* [GitLab](https://gitlab.com) (also uses open core licensing)
* [Moodle](https://moodle.org/)
* [Sentry](https://getsentry.com/)
* [Travis CI](https://travis-ci.org/)
* [WordPress.com](http://wordpress.com/)

## Copyleft + paid license

*Companies selling proprietary software prefer to include permissively licensed code (such as MIT or Apache 2.0) rather than copyleft licensed code (like the GPL) in their software, because the latter requires them to keep the same copyleft terms for their end products. So, some open source projects use a copyleft license by default, but they sell license exceptions, proprietary licenses, or permissive commercial licenses to companies who want to bypass the copyleft requirements.*

#### Pros

* Business model aligned with something people are willing to pay for
* Can scale well if successful

#### Cons

* Can be at odds with making software freely accessible
* Project needs to be big enough that a customer need exists
* Only works for upstream software that's being used in downstream software
* There can be legal or monetary barriers to moving code from open to proprietary 

#### Case Studies

* [Metafizzy](https://metafizzy.co) (ex. [Isotope](https://isotope.metafizzy.co/license.html), [Flickity](https://flickity.metafizzy.co/license.html))
* [MySQL](http://www.mysql.com/about/legal/licensing/oem/)
* [Qt](https://www1.qt.io/faq/#_Toc_3)
* [SQLite](https://www.sqlite.org/copyright.html)

## Open core

*Under an [open core](https://en.wikipedia.org/wiki/Open_core) model, some aspects of the project are free, but other features are proprietary and available only to paid users. Usually this works when there is enterprise demand for the project.*

#### Pros

* Business model aligned with something people are willing to pay for
* Can scale well if successful

#### Cons
* Need to have something you can charge for (which means making certain features exclusive)
* Can be at odds with making software freely accessible
* “Two tiers” of product support can make free users unhappy
* May require a CLA (Contributor License Agreement) to accept code submissions from outside contributors while retaining the ability to relicense those submissions under the proprietary license

#### Case Studies

* [GitLab](https://about.gitlab.com/)
* [Docker](https://www.docker.com/)
* [Elastic](https://www.elastic.co/)
* [Mesosphere](https://mesosphere.com/)
* [Phusion Passenger](https://www.phusionpassenger.com/); see also their talk, ["Bootstrapping a Business Around Open Source"](https://www.youtube.com/watch?v=uHaMpLyMOL0&feature=youtu.be) (video)
* [Sidekiq](http://sidekiq.org/)

## Foundations & consortiums

*A [foundation](https://en.wikipedia.org/wiki/Foundation_(nonprofit)) is a legal entity that can accept and/or disburse donations. Because their purpose is not to make profits, they can be a great choice to signal neutrality and steward a project. In the US, foundations are either 501(c)(3) (nonprofit) or 501(c)(6) (trade consortium). Many software foundations are 501(c)(6) because 501(c)(3) requires demonstrating a charitable purpose, which can be more difficult in software.*

#### Pros

* Neutrality. Foundation protects the code and helps steward the community
* Influence distributed across multiple donors
* Can legitimize project, companies might feel more comfortable giving to foundations than individuals

#### Cons

* Only really worth it for big projects
* Difficult to set up for IRS reasons (many do 501(c)(6) instead of 501(c)(3)), restrictions on what you can do
* Requires serious community effort and diverse skills (you still need to fundraise after setting up the entity!)

#### Case Studies

* [Linux Foundation](https://www.linuxfoundation.org/)
* [Node.js Foundation](https://www.sitepoint.com/goodbye-joyent-hello-node-js-foundation/)
* [Python Software Foundation](https://www.python.org/psf/)
* [Ruby Together](http://rubytogether.org/)
* [Signal Foundation](https://signal.org/blog/signal-foundation/)

## Venture capital

*Venture capital is a form of funding for high growth businesses. Unlike a bank loan or other forms of debt financing, venture capitalists take equity (a percent ownership in your business) in exchange for funding. Unlike taking out a loan, you don't have to repay your creditors if your business tanks. If you do succeed, however, you should expect to return capital to your investor at a multiple.*

*Venture capital is "high risk high reward": VCs are more risk tolerant than banks, but they also expect a large payoff if you are successful. If you plan on raising venture capital, you should set up a business entity structured as a C Corp, preferably in Delaware. If you're unfamiliar with the venture capital process, the best place to start is by reaching out to similar founders who have successfully raised venture.*

#### Pros

* Institutional support can be helpful for growing a business
* Large amounts of capital available

#### Cons

* Venture capital comes with expectations of an exit (i.e. returning the money to investors at a multiple). History suggests this is structurally difficult to achieve for open source businesses. Venture Capital isn't actually a business model but only investment capital for those who have some *other* business model for future revenue.
* Venture capital can change motivations and distract from priorities
* Unavailable to non-profits

#### Case Studies

* [Confluent](http://www.confluent.io/blog/confluent-raises-a-series-b-funding)
* [Gatsby](https://www.gatsbyjs.org/blog/2018-05-24-launching-new-gatsby-company/)
* [Meteor](http://info.meteor.com/blog/announcing-our-20m-series-b-funding)
* [NodeSource](https://techcrunch.com/2015/02/09/nodesource-raises-3-million-to-build-new-programming-tools/)
* [Npm](http://blog.npmjs.org/post/76320673650/funding)
* [OSS Capital](https://oss.capital/)

## Restricted license

*Restricted licenses (reminiscent of the older [shareware](https://en.wikipedia.org/wiki/Shareware) movement) are **not open source** because they do not meet [the definition](https://en.wikipedia.org/wiki/The_Open_Source_Definition) of an open source license. The source code is made available (either publicly, or to customers who pay for a license), but they may limit the freedoms to redistribute and modify or to use the software commercially.*

#### Pros

* Business model aligned with something people are willing to pay for
* Potential to scale well if successful

#### Cons

* Not actually open source (so may fail to achieve many or most of the benefits of open source)
* Can be controversial, erode community trust

#### Case Studies

* [BSL (Business Source License)](https://mariadb.com/bsl-faq-adopting), used by [MariaDB](https://mariadb.com/)
* [Fair Source](https://fair.io/), used by [Sourcegraph](https://sourcegraph.com/)
* [License Zero](https://medium.com/licensezero/the-license-zero-manifesto-fecb7aaf4c0a)
* [Markdown Monster](https://markdownmonster.west-wind.com/)
  * Source code is viewable, but [a license must be purchased](https://markdownmonster.west-wind.com/download.aspx) for continued use
  * Project contributors are [eligible for a free license](https://markdownmonster.west-wind.com/download.aspx#Contribute)
* [Onivim 2](https://github.com/onivim/oni2#license)
  * Commercial license is pay-what-you-want, with the minimum pre-order price increasing as they get closer to shipping an MVP
  * Anyone who financially sponsors the OSS project gets a free lifetime license
  * Commits are dual-licensed with MIT after 18 months from the commit's date to master
* [Redis Commons Clause](https://redislabs.com/community/licenses/)
* [Ungit switched back from Faircode to MIT License](https://github.com/FredrikNoren/ungit/issues/997)


---

### Contributing to this guide

I wrote up this guide to aggregate my knowledge. I recognize the pros/cons are somewhat subjective, but they reflect my views. If you submit changes, I may consider them but do not intend to cover everyone's viewpoints.

If something is factually incorrect (especially with a case study example), I welcome your edits. Case studies are organized alphabetically within each category. Also, if there's a category you know of that I missed, I would welcome that addition.

### License and attribution

This guide is available under the Creative Commons CC0 1.0 License, meaning you are free to use it for any purpose, commercial or non-commercial, without any attribution back to me (public domain). If you do use it, I'd love to hear about it! (Find me here: [@nayafia](http://twitter.com/nayafia)) But you are in no way required to do so.
Download .txt
gitextract_d2g6j7_9/

├── LICENSE
└── README.md
Condensed preview — 2 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (35K chars).
[
  {
    "path": "LICENSE",
    "chars": 6555,
    "preview": "CC0 1.0 Universal\n\nStatement of Purpose\n\nThe laws of most jurisdictions throughout the world automatically confer\nexclus"
  },
  {
    "path": "README.md",
    "chars": 28183,
    "preview": "# A handy guide to financial support for open source.\n*\"I do open source work, how do I find funding?\"*\n\nThis document a"
  }
]

About this extraction

This page contains the full source code of the nayafia/lemonade-stand GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 2 files (33.9 KB), approximately 8.1k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.

Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.

Copied to clipboard!