Repository: pybee/paying-the-piper
Branch: master
Commit: 741da924f4fd
Files: 4
Total size: 11.2 KB
Directory structure:
gitextract_1ytqepdr/
├── .gitignore
├── CODE_OF_CONDUCT.md
├── README.md
└── who_are_your_customers.md
================================================
FILE CONTENTS
================================================
================================================
FILE: .gitignore
================================================
mynotes_*
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Code of Conduct
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses, without explicit permission
* Other unethical or unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.2.0, available at [http://contributor-covenant.org/version/1/2/0/](http://contributor-covenant.org/version/1/2/0/).
================================================
FILE: README.md
================================================
# Paying the piper
A project for discussing ways to fund open source development.
## The problem
At this point in time, we don't need to convince anyone that the Open Source development process yields exceptional quality software. It also yields better results for users - better security, less vendor lock in, and so on.
However, what the FOSS community hasn't tackled well is the issue of paying for the development of FOSS. To date, most open source code is either:
1. Developed as an in-house project by a company, and open sourced for strategic advantage ([commodifying a complement](http://www.joelonsoftware.com/articles/StrategyLetterV.html))
2. Developed entirely by volunteers.
In some cases, a combination of the two is used.
When volunteered in small quantities, there's nothing wrong with volunteers contributing to an open source project. However, leading an open source project - especially a large one - can become an all-consuming activity, absorbing all a volunteer's free time, and then some.
As a result, burnout is a regular feature in FOSS communities. This isn't a healthy from a personal perspective; and as an industry, it's frightening how much of the infrastructure on which we rely on on a daily basis is maintained by complete volunteers.
It's especially concerning given the amount of money that is available in the software development community.
The usual answers to this problem are:
1. **Start a consulting company.** This is a nice idea, but it rarely works in practice. As soon as you are a consultant, the economic realities of running a company mean you focus on making money - and the things that people are willing to pay consultants for are rarely directly aligned with the long term maintenance tasks of a project.
2. **Give away the razor, sell razor blades.** This works fine as long as your project has some add on that can be sold. However, not all projects can do this.
3. **Find a patron company.** Get employed by a company that is willing to take on the economic "burden" of hiring a developer that doesn't contribute directly to their own bottom line. There's also the equity issue - why should one company pick up the tab for an entire developer, when their neighbour/competitor who uses the same software doesn't contribute at all?
These three approaches also lend themselves to maintaining existing projects, not starting new projects. The FOSS equivalent of "Venture capital" doesn't exist.
New models for funding FOSS development are clearly needed. The purpose of this project is to collect and discuss ideas for new funding models, in the hope that as a community of software developers, we can solve this problem, and see less of our friends and colleagues burn out in front of us.
## What this project isn't
There are lots of ideas out there already about open source development on the small scale. 20% time, [The Two Day Manifesto](http://twodaymanifesto.com) ([archive](https://archive.is/2015.04.13-190754/http://twodaymanifesto.com/)), and related ideas area all about employees finding small pieces of time inside their existing employment engagements to contribute to Open Source. These are all welcome contributions, but it's not the problem we're trying to solve here.
In addition to lots of small contributions, there is a need for dedicated, full time attention. The larger the project, the bigger this need becomes. A large project (something like a web framework, or a programming language, or a widget toolkit) requires the dedicated attention of one person - or preferably more - to provide high level design guidance, to design and develop the huge features, and just keep the wheels turning for all the smaller contributions. Funding *these* individuals - full time, dedicated project management and contribution staff - is the problem that needs to be solved.
## How to contribute
Please, before contributing, read our [Code Of Conduct](CODE_OF_CONDUCT.md).
Have you got an idea for a way that we could pay for FOSS development? Open a ticket, and start a discussion around the specifics of that idea.
Do you know of a video, book, blog post, or other resource that you think people should read? Submit a PR against this readme.
## Resources
* [Money Money Money: Writing software, in a rich (wo)man's world - Russell Keith-Magee](https://www.youtube.com/watch?v=mY8B2lXIu6g)
* [Funding FOSS - Noah Kantrowitz](https://coderanger.net/funding-foss/)
* [Open Source Funding Models - Marcus Kazmierczak](https://mkaz.blog/misc/open-souce-funding-models/)
* [nayafia/lemonade-stand - A handy guide to financial support for open source](https://github.com/nayafia/lemonade-stand)
* Books that may be useful individually or in total, for people who haven't had to give much thought to business models in the past:
* [Business Model Generation](http://www.amazon.com/Business-Model-Generation-Visionaries-Challengers/dp/0470876417/): A general, succinct approach to looking at business model ideas
* [Business Model You](http://www.amazon.com/Business-Model-You-One-Page-Reinventing/dp/1118156315/): Same as above, but applied to INDIVIDUAL careers. This may be useful to current contributors trying to figure out how to find a 'business model' that works better for them.
* [Value Proposition Design](http://www.amazon.com/Value-Proposition-Design-Customers-Strategyzer/dp/1118968050/): A more detailed look at how to provide something of value to customers, a.k.a., "something people will pay for".
* [Producing Open Source Software](http://producingoss.com/) : A complete guide to the human side of managing an open source project, contains sections on funding models but gives some insights into how to manage a sucessful FOSS project. Written by [Karl Fogel](http://www.red-bean.com/kfogel/)
## License
All content submitted to this project is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
================================================
FILE: who_are_your_customers.md
================================================
# Identify your customers
## Rationale
This is a result of spending a weekend at [Innovate Houston](http://cvcx.org/accelerate-houston-2/), working to develop a viable business model for Django (and, by extension, other FLOSS projects). One thing we did was use the [Impact Canvas](http://www.socialblueprint.org/wp-content/uploads/2015/02/ISA_The-Social-Blueprint_-Impact-Canvas_v3.21.pdf), a version of the [Business Model Canvas](http://www.businessmodelgeneration.com/canvas/bmc). For those unfamiliar, the BMC is a 1 page way to quickly see the key points of your business model, to see if they make sense.
1. During conversations with **non-developers**, they were shocked to hear that organizations they knew (like Instagram & Pinterest) were using FLOSS but NOT contributing to or supporting those projects. While I spoke to people about Django *specificially*, I'm going to assume this is true for MOST FLOSS projects. Most non-developers aren't aware of this issue.
2. As we dug into the BMC move, a few key questions popped out. These seem like questions LOTS of FLOSS projects need to have answers to.
1. Who ARE your customers?
2. What is the your project's relationship WITH those customers? Does it HAVE one?
3. How does your project REACH or INTERACT with those customers?
This document focuses mostly on point 2. If there's GOING to be a business model, you need CLEAR answers to ALL of three of the sub-points to point 2. If you don't know WHO you're doing business with, you're not really *in* business.
Some quick thinking makes it clear that there are at LEAST two different groups of (commercial) customers, ie "people using it for business", for most projects:
- Large, commercial customers: (any well-know commercial enterprise using your project)
- Smaller (1-10 person? Pick a value of *small*) commercial users: these may be consultants or smaller commercial enterprises using your project.
Focusing on the larger, commercial customers, it would be useful to *start* a list of "large" users of your project (with 'large' NOT being well defined at the moment). The goal is to start identifying customers and figuring out what kind of relationship your project does or can have with them. Know WHO they are will also shed light on *how* to create something they will value. Which leads to creating a value exchange based ON that relationship. There may be things I'm NOT aware of, but as far as I know now, the relationship of a LOT of FLOSS projects to their customers is:
> Customers: We download `insert your FLOSS project here` and use it.
> FLOSS Project Community: We update, maintain and upload `insert your FLOSS project here`, so people can download and use it.
There's no business model there. Identifying the customers more clearly makes it possible to identify spaces for value creation. You can't give a stranger what they want. You don't KNOW what they want. Because they're a stranger.
## Going forward
This isn't intended to be a complete or exhaustive list, it's TWO things:
- A starting point, for listing significant customers of your FLOSS project.
- A starting point, as far as **thinking about** customers of your FLOSS project. Who are they? What do they want/need? How can we provide it AND capture some of the value?