diff --git a/getting-started/branding.md b/getting-started/branding.md index 888ec0bd861..5cf2741226f 100644 --- a/getting-started/branding.md +++ b/getting-started/branding.md @@ -15,9 +15,9 @@ Pick a name that is easy to remember and, ideally, gives some idea of what the p Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. For example, some of your users might be employees; you don’t want to make them uncomfortable when they have to explain your project’s name to coworkers! -## Avoiding namespace conflicts +## Avoiding name conflicts -Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov). +Make sure that your project’s name doesn’t infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It’s just not worth the risk. You can check for U.S. trademark conflicts [here](http://www.uspto.gov/trademarks-application-process/search-trademark-database). If you’re at a company, this is one of the things your [legal team can help you with](../legal/#what-does-my-companys-legal-team-need-to-know). You’ll also want to look for open source projects with a similar name, especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you will confuse your audience and make it less likely that anyone will use what you’ve created. You can check for similar project names [here](http://ivantomic.com/projects/ospnc/). diff --git a/getting-started/index.md b/getting-started/index.md index 4ec3b7c9ae7..e98a33220dc 100644 --- a/getting-started/index.md +++ b/getting-started/index.md @@ -9,17 +9,17 @@ So you’re interested in making your project open source? Congratulations! 🎉 Before we get into the details of running and managing an open source project, let’s talk about what open sourcing a project actually means. -## Public projects on GitHub are not open source +## Public projects on GitHub without a license are not open source When you publish a project on GitHub, you have the option to make the repository **private** or **public**. A public repository is not automatically open source unless you pick a license that grants a certain set of rights to people who might interact with your project. Open source licenses grant permission to everyone to use, modify, and share licensed software for any purpose, subject to certain conditions, depending on the license. -Public repositories on GitHub [comply with GitHub’s Terms of Service](https://help.github.com/articles/open-source-licensing/), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) +Public repositories on GitHub are covered by [GitHub’s Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which gives other people the right to view and fork your repository. But if you want others to use, copy, modify, or contribute back to your project, you need to [include an open source license](https://help.github.com/articles/open-source-licensing/). For example, someone cannot legally use any part of your GitHub project in their code, even if it’s public, unless you explicitly give them the right to do so. (You can learn more about the legal side of open source [here](legal/).) -## Open source is more than just a license +## Open source is more than just source code with a license -Open source is defined by its legal protections and freedoms. In terms of culture, open sourcing a project has come to mean much more. +Open source is [defined by](https://opensource.org/osd) source code with legal protections and freedoms. In terms of culture, open sourcing a project has come to mean much more. There are many reasons why a person or organization might want to open source a project. Some examples are: diff --git a/getting-started/legal.md b/getting-started/legal.md index e5e027af67d..185027b2f03 100644 --- a/getting-started/legal.md +++ b/getting-started/legal.md @@ -10,75 +10,86 @@ Thankfully, you don’t have to start from scratch. This section will make sure ## Table of Contents -1. [Why do I need an open source license?](#why-do-i-need-an-open-source-license) -2. [Which open source license is appropriate for me?](#which-open-source-license-is-appropriate-for-me) -3. [Do I need a contributor agreement in addition to my open source license?](#do-i-need-a-contributor-agreement-in-addition-to-my-open-source-license) -4. [I’m a company open sourcing a project. What does my legal team need to know?](#im-a-company-open-sourcing-a-project-what-does-my-legal-team-need-to-know) -5. [I’m using others’ open source code. What does my legal team need to know?](#im-using-others-open-source-code-what-does-my-legal-team-need-to-know) +1. [Why does my project need an open source license?](#why-does-my-project-need-an-open-source-license) +2. [Which open source license is appropriate for my project?](#which-open-source-license-is-appropriate-for-my-project) +3. [Does my project need an additional contributor agreement?](#does-my-project-need-an-additional-contributor-agreement) +4. [What does my company’s legal team need to know?](#what-does-my-companys-legal-team-need-to-know) -## Why do I need an open source license? +## Why does my project need an open source license? -When you publish a creative work (which includes code), your work is under copyright by default. Unless you include a license that specifies otherwise, nobody can copy or modify your work without being subject to copyright law. +When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), "nobody" starts including you. -An open source license guarantees that others can use, modify, and share your project. It protects both you and anybody else who might interact with your project. +An open source license guarantees that everyone can use, modify, and share your project. It protects both you and anybody else who might interact with your project. -Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work is otherwise copyrighted unless you add an open source license. +Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work otherwise comes with no permissions unless you add an open source license. -## Which open source license is appropriate for me? +Also, the licenses of your project’s dependencies, the communities you hope will use your project, or your employer’s policies may effectively require your project to use an open source license, even a specific open source license. We’ll cover these situations below. -There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that comply with the generally accepted definition of open source. Here is a breakdown of three of the most common licenses. +## Which open source license is appropriate for my project? -* **For individuals releasing an open source project with no deeper interests,** consider the [MIT License](http://choosealicense.com/licenses/mit/), which is simple and permissive. People can use your project for whatever they like, as long as they provide attribution back to you and don’t hold you liable for anything. -* **For companies releasing an open source project,** consider the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/). The Apache 2.0 license is appropriate for project owners who are concerned about patents. It provides an express grant of patent rights from contributors. -* **For those who care about keeping their code in the public domain,** consider the [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/), which is a copyleft license. That means anyone who distributes your code, or a derivative of your work, must make the source available under the same terms. It also provides an express grant of patent rights from contributors. +If you’re starting from a blank slate, it’s hard to go wrong with the [MIT License](http://choosealicense.com/licenses/mit/). It’s short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You’ll be able to release the project under a different license if you ever need to. -If your open source project isn’t software, consider a Creative Commons or other type of license that’s tailored for media. You can read more about choosing a non-software license [here](http://choosealicense.com/non-software/). +Otherwise, picking the right open source license for your project depends on your objectives. -When you create a new project on GitHub, you are given the option to select a license. Including one of the above licenses will make your GitHub project open source. If you’d like to see other license options, check out [Choose a License](http://choosealicense.com) to find the right license for you. +Your project very likely has (or will have) **dependencies**. For example, if you’re open sourcing a Node.js project, you’ll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. -## Do I need a contributor agreement in addition to my open source license? +On the other hand, if any of your dependencies’ licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. -Some open source projects, particularly when companies are involved, require a contributor agreement. These are legal agreements that must be signed by a contributor before they can make changes to the project. +You may also want to consider the **communities** you hope will use and contribute to your project: -Contributor agreements are used when the project owner wants to protect themselves, and their users, from future copyright claims from contributors. There are two major types of contributor agreements: +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](http://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/npm). +* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](http://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](http://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](http://choosealicense.com/licenses/agpl-3.0/) will go over well. -* [Contributor License Agreement (CLA)](https://www.apache.org/licenses/icla.txt): A CLA explicitly grants the project owner the right to distribute all contributions made by the contributor, either by assigning copyright or granting an irrevocable license. Some projects specify that CLAs only need to be signed for “non-trivial changes”: for example, fixing a significant bug rather than a small typo. -* [Developer Certificate of Origin (DCO)](http://developercertificate.org/): A DCO certifies that the contributor has the right to make their contribution and that they allow the project owner to use it in other distributions. Unlike a CLA, which must be explicitly signed, a DCO is required as a signature when the contribution is submitted, or is part of the project’s contribution policy. +Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company’s closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your company’s legal department (also see below). -There are some concerns associated with CLAs in particular. CLAs can be perceived as not friendly to the project’s community. They can also create a lot of administrative work for the project owner. Finally, CLAs increase the barrier to community participation by adding more paperwork than some believe is necessary. +When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you’d like to see other options, check out [ChooseALicense.com](http://choosealicense.com) to find the right license for your project, even if it [isn’t software](http://choosealicense.com/non-software/). -Many projects that use a CLA are concerned about patents. If you have patent concerns, consider adopting a license with patent protections instead, such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/), in which contributors expressly grant patent rights. +## Does my project need an additional contributor agreement? -You can also consider using a DCO, which is less cumbersome than signing an agreement and provides similar benefits to a CLA. If your project is on GitHub, include the DCO in your CONTRIBUTING.md file, which is automatically referenced when someone submits a pull request. Or you can require that contributors include the DCO as a signature when they submit a pull request. +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. -## I’m a company open sourcing a project. What does my legal team need to know? +Contributor agreements can create additional administrative work for project maintainers. How much work these agreements add depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors’ employers. -If you are a company open sourcing a project, there are a few legal aspects you may want to consider. +In addition, contributor agreements are sometimes perceived as not friendly to the project’s community. They can also increase the barrier to community participation by adding more paperwork than some believe is necessary. -* **Existing Intellectual Property (IP):** Consider whether there is anything existing in the project that might fall under company IP, which you would not want to make available to the general public. If so, you could open source the rest of your project, but keep the IP private. -* **Future Patents:** If you are concerned that there may be patents associated with your project later on, use an open source license that provides patent protections (such as the [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/)). -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects, especially if you expect employees to maintain the project. A clear corporate policy will reduce confusion among your employees and encourage them to make open source contributions during work hours. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). -* **Trademarks:** Double check that your project’s name does not conflict with any existing trademarks. If you use your own company trademarks in the project, check that it does not cause any conflicts. +Here are some situations where you may want to consider an additional contribution agreement for your project: -These are starting points for conversation. Be sure to run any open source project by your legal team before proceeding! +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. For some projects, a [Developer Certificate of Origin](http://developercertificate.org/) can be an even simpler alternative. +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project’s other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.txt) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. -## I’m using others’ open source code. What does my legal team need to know? +If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. -The implications of using others’ open source code in your software depends on that project’s license. (If the project does not have an open source license, don’t use it!) +## What does my company’s legal team need to know? -Some open source licenses, like the GNU GPLv3, require that any software using the code must license the source under the same terms. If you are a company using code with these restrictions, you will want to proceed carefully. +First, they should know that you’re open sourcing a project. -Other open source licenses, like the MIT license, are very permissive. They may still require attribution. +For better or worse, consider letting them know even if it’s a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company’s business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company’ professional learning and development objectives for you), or avoid working on your project until you find a better company. -If you use others’ open source code to create anything that could be considered company IP, you will want to read the terms of the license carefully to understand your patent rights. +If you’re open sourcing a project for your company, then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company’s business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: -To learn more about the implications of different open source licenses, [TLDRLegal](https://tldrlegal.com/) is a great resource. +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others’ code? If these are open source, you’ll need to comply with the materials’ open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you’re meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others’ code that does’t have an open source license, you’ll probably have to ask the third party maintainers to [add an open source license](http://choosealicense.com/no-license/#for-users), and if you can’t get one, stop using their code in your project. +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material the you want to keep private. +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you’re expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **Trademarks:** Double check that your project’s name [does not conflict with any existing trademarks](../branding/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. + +If you’re releasing your company’s first open source project, the above is more than enough to get through (but don’t worry, most projects shouldn’t raise any major concerns). + +Longer term your legal team can do more to help the company get more from its involvement in open source, and stay safe: + +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company’s best interest, whether as part of their jobs or in their free time. A good example is Rackspace’s [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). +* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company’s open source strategy, they’ll be best able to help rather than hinder your efforts. +* **Compliance:** Even if your company doesn’t release any open source projects, it uses others’ open source software. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) can prevent headaches, product delays, and lawsuits. +* **Patents:** Your company may wish to join the [Open Invention Network](http://www.openinventionnetwork.com/), a shared defensive patent pool to protect members’ use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../../sustaining/leadership/#do-i-need-a-legal-entity-to-support-my-project). ## Further reading * [ChooseALicense.com](http://choosealicense.com) -* [TLDRLegal](https://tldrlegal.com/) -* [A Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) +* [Over 70 approved licenses](https://opensource.org/licenses/alphabetical) that conform with the generally accepted definition of open source +* [A Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) by @vanl * [Introducing The Docker Developer Certificate Of Origin](https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/) by @keeb -* [Broadening Node.js Contributions -](https://www.joyent.com/blog/broadening-node-js-contributions) by @bcantrill +* [Broadening Node.js Contributions](https://www.joyent.com/blog/broadening-node-js-contributions) by @bcantrill +* [FOSSmarks](http://fossmarks.org/) is "a practical guide to understanding trademarks in the context of Free and Open Source projects." diff --git a/getting-started/preparing.md b/getting-started/preparing.md index a3544b22105..fef36983348 100644 --- a/getting-started/preparing.md +++ b/getting-started/preparing.md @@ -12,7 +12,7 @@ Every open source project should include the following: * Contributing guide * Code of conduct -As a maintainer, these components will help you communicate expectations, manage contributions, protect your legal rights, and make sure that you and your contributors have a positive experience. The more you can document for your readers up front, the less work you’ll have to do later on. +As a maintainer, these components will help you communicate expectations, manage contributions, protect your, contributors’, and users’ legal rights, and make sure that you and your contributors have a positive experience. The more you can document for your readers up front, the less work you’ll have to do later on. ## Choosing a license @@ -20,14 +20,7 @@ An open source license guarantees that others can use, copy, modify, and contrib Legal work is no fun. The good news is there are many licenses available that you can copy and paste into your repository. It will only take a minute to protect your hard work. -There are [over 70 approved licenses](https://opensource.org/licenses/alphabetical) that comply with the generally accepted definition of open source. Some licenses you’ll commonly hear about are: - -* [MIT License](http://choosealicense.com/licenses/mit/) -* [Apache License 2.0](http://choosealicense.com/licenses/apache-2.0/) -* [Mozilla Public License 2.0](http://choosealicense.com/licenses/mpl-2.0/) -* [GNU General Public License v3.0](http://choosealicense.com/licenses/gpl-3.0/) - -When you create a new project on GitHub, you are given the option to select a license. Including one of these licenses will make your GitHub project open source. (Different licenses carry slightly different permissions. You can use [ChooseALicense.com](http://choosealicense.com) to find the right license for you.) +When you create a new project on GitHub, you are given the option to select a license. Including one of these licenses will make your GitHub project open source. (You can use [http://choosealicense.com](http://choosealicense.com) to find the right license for your project.) If you have other questions or concerns around the legal aspects of managing an open source project, we've got you covered: [The legal side of open source](../legal/) @@ -60,21 +53,21 @@ A CONTRIBUTING file tells your audience how to participate in your project. For In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions. Remember that no two open source projects are alike. Write down rules that work best for you and your lifestyle. For example, you may want to convey that you are only accepting certain types of contributions, tell participants how long they should expect to hear a response from you, or explain how (or how not) to get in touch with you. -If you are a community project, you can use the CONTRIBUTING file to actively solicit the types of contributions you’re looking for. Using a warm, friendly tone and offering specific contribution suggestions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. +The CONTRIBUTING file is a place to clearly state the types of contributions you’re looking for. Using a warm, friendly tone and offering specific contribution suggestions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. You should reference your CONTRIBUTING file in your README. In your README, give your audience a quick overview of how contributions work, then link to the CONTRIBUTING file for more information. If you place your CONTRIBUTING file in the root directory, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. -## Writing a code of conduct +## Establishing a code of conduct -Finally, a code of conduct helps set ground rules for communication among your project’s participants. The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Angular Code of Conduct](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) are two good examples. +Finally, a code of conduct helps set ground rules for behavior of your project’s participants. This is especially valuable if you’re launching an open source project for a community or company. -A code of conduct is a place to convey the values or philosophy that define your project. This is especially valuable if you’re a community or company launching an open source project. +In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your project’s root directory. -Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. You can read more about enforcing codes of conduct [here](../../troubleshooting/conduct/). +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Angular Code of Conduct](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) are two good examples. The [Contributor Covenant](http://contributor-covenant.org/) is a code of conduct used by [many projects](http://contributor-covenant.org/adopters/). -In addition to communicating your expectations, you should describe what happens if someone violates the code of conduct, and where someone can report such behavior. We recommend placing a CODE_OF_CONDUCT file in your root directory. +Codes of conduct help protect not just your participants, but yourself. As you maintain your project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive about these expectations reduces the likelihood that you, or others, will become fatigued with your project later on. You can read more about enforcing codes of conduct [here](../../troubleshooting/conduct/). ## What’s next? @@ -87,7 +80,6 @@ Sometimes, it will take a long time before people notice your open source projec ## Further reading * Licenses - * [Choosing an Open Source License](https://github.com/blog/1530-choosing-an-open-source-license) by @haacked * [ChooseALicense.com](http://choosealicense.com) * READMEs * [Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) by @mojombo @@ -101,6 +93,7 @@ Sometimes, it will take a long time before people notice your open source projec * [Contributing Guides: A Template](https://github.com/nayafia/contributing-template) by @nayafia * [Wrangling Web Contributions: How to Build a CONTRIBUTING.md](http://mozillascience.github.io/working-open-workshop/contributing/) * Codes of conduct + * [Code of conduct evaluations](http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations) from the Geek Feminism wiki * [Contributor Covenant](http://contributor-covenant.org/) * [Django Code of Conduct](https://github.com/django/code-of-conduct) * [HOWTO design a code of conduct for your community](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) by Valerie Aurora diff --git a/getting-started/setting-expectations.md b/getting-started/setting-expectations.md index 86e271f7f41..309d7d769e3 100644 --- a/getting-started/setting-expectations.md +++ b/getting-started/setting-expectations.md @@ -13,7 +13,7 @@ Let’s start by defining your goals. Simply put: _why are you open sourcing thi There is no one right answer to this question. You may find that you have multiple goals for a single project, or that different projects have different goals. The most important thing is to be honest with yourself. -Here are some examples of reasons why people open source their work: +Here are some examples of [reasons](http://ben.balter.com/2015/11/23/why-open-source/) why people open source their work: * An individual wants to show off their portfolio * An individual or company wants others to use what they’ve created @@ -33,7 +33,7 @@ If you’re hoping to get feedback on something you’ve created, consider askin ## Figure out what others need from you -Finally, open sourcing a project is a two-way street. People who use your project will probably ask you for things, too. +Open sourcing a project is a two-way street. People who use your project will probably ask you for things, too. Try to anticipate these needs beforehand so you can add them to your project from the beginning. Successful open source projects try to document as much as they can in public. Much like reusable pieces of code, reusable information means less people need to ask you the same questions over and over again. (That means less work for you!)