From 01973b658dcc8e613dee6efd42b2784512ee65c4 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Fri, 22 Jul 2016 23:03:37 -0400 Subject: [PATCH 1/6] Add getting started content from @nayafia --- _content/getting-started/branding.md | 47 +++++++++ _content/getting-started/index.md | 35 +++++++ _content/getting-started/preparing.md | 98 +++++++++++++++++++ .../getting-started/setting-expectations.md | 63 ++++++++++++ _content/index.md | 9 ++ 5 files changed, 252 insertions(+) create mode 100644 _content/getting-started/branding.md create mode 100644 _content/getting-started/index.md create mode 100644 _content/getting-started/preparing.md create mode 100644 _content/getting-started/setting-expectations.md create mode 100644 _content/index.md diff --git a/_content/getting-started/branding.md b/_content/getting-started/branding.md new file mode 100644 index 00000000000..9f886b72979 --- /dev/null +++ b/_content/getting-started/branding.md @@ -0,0 +1,47 @@ +# **Branding** + +You’ve thought about who your users are, what they need from you, and what you might be able to offer them. Next, we’ll put that research into practice as we consider the brand of your project. + +Branding may sound like a waste of time. After all there, are plenty of popular open source projects that have never thought about their brand at all. + +But branding is more than a flashy logo or catchy project name. It’s about how you talk about your project and who you reach with your message. Here are a few things you’ll want to think about before you launch. + +## Choosing the right name + +Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example, [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting, and [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server. + +Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Be clever, but not so clever that the name gets in the way of adoption. For example, some of your users might be company employees; you don’t want to make them uncomfortable when they have to explain your project to coworkers! + +## Namespace 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](http://www.uspto.gov) + +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/](http://ivantomic.com/projects/ospnc/) + +Consider whether you’ll want a website, Twitter handle, or other properties to represent your project. If so, make sure you can get the names you want. Ideally, reserve those names now so you have peace of mind. You can check for domain name availability here: [https://instantdomainsearch.com/](https://instantdomainsearch.com/) + +Finally, it doesn’t hurt to do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn’t want them to see? + +## How you write (and code) affects your brand, too! + +Throughout the life of your project, you’ll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. How you write, whether it’s official documentation or a casual email, contributes to the brand of a project. Consider how you might come across to your audience and whether that is the tone you wish to convey. + +[@janl](https://github.com/janl) discovered that the way he spoke to others helped create a positive brand for [CouchDB](https://github.com/apache/couchdb): + +*When I started out at CouchDB and we finally joined the ASF and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.* + +*My responsibilities since have shifted quite a bit and I’m no longer checking on the user@ mailing list day-to-day, but every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.* + +[http://writing.jan.io/2015/11/20/sustainable-open-source.html](http://writing.jan.io/2015/11/20/sustainable-open-source.html) * * + +Beyond how you write words, your coding style may also become part of your project’s brand. For example, [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](http://contribute.jquery.org/style-guide/js/) are two projects with rigorous coding styles and guidelines. + +It isn’t necessary to write a style guide for your project when you’re just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing (and coding) style might attract (or not attract) different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. + +We’re almost there! Next, we’ll walk you through a few components that every open source project should include when you launch. + +## Related Content + +* [http://producingoss.com/en/getting-started.html#choosing-a-name](http://producingoss.com/en/getting-started.html#choosing-a-name) + +[Previous](setting-expecations.md) | [Next](preparing.md) diff --git a/_content/getting-started/index.md b/_content/getting-started/index.md new file mode 100644 index 00000000000..36733ee73ef --- /dev/null +++ b/_content/getting-started/index.md @@ -0,0 +1,35 @@ +# Before You Get Started + +## What does it mean to open source a project? + +So you’re interested in making your project open source? Congratulations! 🎉 🙌 🌟 The world appreciates your contribution. + +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 + +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. **(See also: link to license/legal article here)** + +## Open source is about more than just 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. + +There are many reasons why a person or organization might want to open source a project. Some examples are: + +* **Transparency:** Making your code visible means that anyone can inspect it for errors or inconsistencies. Transparency matters to government (like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/)), regulated industries like banking or healthcare, and security-related software infrastructure (like [Let’s Encrypt](https://github.com/letsencrypt)). + +* **Collaboration:** Projects that are open source can accept changes and updates from anybody. Collaboration matters to those who want to build their projects with a community, like [Hoodie](https://github.com/hoodiehq) and [Rust](https://github.com/rust-lang/rust). When people make improvements together, projects can thrive, because they draw from multiple skill sets, experiences, and levels of involvement. + +* **Adoption and remixing:** Open source projects can be used by anyone for any purpose, whether it’s making a custom version of the original project, or using that project to build something else entirely. Code can reach more people when it is shared and reused, like [React](https://github.com/facebook/react) or [Sentry](https://github.com/getsentry/sentry). And new projects can grow out of older projects, like [WordPress and b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md), or [Jenkins and Hudson](https://github.com/jenkinsci). + +Remember: open source isn’t just for software! You can open source everything from data sets to websites to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. + +When you open source a project, you open yourself to feedback and suggestions from other people who are engaged with your work. It might feel intimidating to open source a project for the first time, but remember that you’re not alone. + +In the next section, we’ll help you figure out your goals around open sourcing your project. Understanding these goals beforehand will make it easier to manage your and others’ expectations later on. + +[Previous](../index.md) | [Next](setting-expectations.md) diff --git a/_content/getting-started/preparing.md b/_content/getting-started/preparing.md new file mode 100644 index 00000000000..acfe04528be --- /dev/null +++ b/_content/getting-started/preparing.md @@ -0,0 +1,98 @@ +# Preparing for launch + +You’re almost ready to launch your project! In this section, we’ll talk about what to include in an open source project before releasing it to the world. + +Every open source project should include the following: + +* License +* README +* Contributing guide +* Code of conduct + +As a maintainer, these components will help you communicate expectations, manage contributions, protect your legal rights, and generally facilitate 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 + +An open source license guarantees that others can use, copy, modify and contribute back to your project without repercussions. It also protects you from any sticky legal situations. + +Legal work is no fun, but the good news is there are many licenses available that you can copy-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 [http://choosealicense.com](http://choosealicense.com) to find the right license for you.) + +(include image of license selection on GitHub new repo here?) + +## Writing a README + +Your project’s README file gives your reader context about the project. + +The README does more than explain how to use your project. It should also help your audience understand why the project is useful and what they can do with it. + +In your README, try to answer the following questions: + +* What does the project do? +* As a user, how does this project help me? +* How do I get started? +* Where can I get more help, if I need it? + +You can also use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. + +Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don’t want contributions. These are all very good reasons to write one! + +As a maintainer, READMEs are an opportunity to clarify your goals in public. If you don’t want to accept contributions, or your project is not yet ready for production, you should especially write this information down. That way, people understand your needs as soon as they arrive to your project. + +When you include a README file in the root directory, GitHub will automatically display it on your project repository’s homepage. It will be the first thing someone sees when they arrive. + +## Setting your contributing guidelines + +A CONTRIBUTING file tells your audience how to participate in your project. For example, you might want to tell your reader how to create an issue, file a bug report, test fixes, or format code. + +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. + +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 + +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. + +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. + +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. ** (Link to: troubleshooting article about dealing with negative actors.)** + +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. + +## What’s next? + +Now that you have these four files in the root directory of your project, you’re ready to open source your project! Click "publish" and pat yourself on the back. Then continue on to the next section. We’ve got work to do. + +Launching your project is only the first step. If you’re looking for feedback or users, you’ll want to make sure other people know about your project. Over the years, your project will likely go through multiple phases of activity and contributorship. That’s okay! The rest of this handbook is designed to help you manage your project every step of the way. + +## Related content + +* Licenses + * [https://github.com/blog/1530-choosing-an-open-source-license](https://github.com/blog/1530-choosing-an-open-source-license) + * [http://choosealicense.com](http://choosealicense.com) +* READMEs + * [http://tom.preston-werner.com/2010/08/23/readme-driven-development.html](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) + * [https://github.com/matiassingers/awesome-readme](https://github.com/matiassingers/awesome-readme) + * [https://pages.18f.gov/open-source-guide/making-readmes-readable/](https://pages.18f.gov/open-source-guide/making-readmes-readable/) + * [https://changelog.com/a-beginners-guide-to-creating-a-readme/](https://changelog.com/a-beginners-guide-to-creating-a-readme/) + * [https://gist.github.com/jxson/1784669](https://gist.github.com/jxson/1784669) +* Contributing guides + * [https://github.com/blog/1184-contributing-guidelines](https://github.com/blog/1184-contributing-guidelines) + * [http://www.contribution-guide.org/](http://www.contribution-guide.org/) + * [https://github.com/nayafia/contributing-template](https://github.com/nayafia/contributing-template) +* Codes of conduct + * [http://contributor-covenant.org/](http://contributor-covenant.org/) + * [https://github.com/django/code-of-conduct](https://github.com/django/code-of-conduct) + * [https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) diff --git a/_content/getting-started/setting-expectations.md b/_content/getting-started/setting-expectations.md new file mode 100644 index 00000000000..ad2177de88a --- /dev/null +++ b/_content/getting-started/setting-expectations.md @@ -0,0 +1,63 @@ +# Setting expectations + +There are many reasons to open source a project. Before going public with your project, it’s a good idea to figure out yours. What you want to get out of the experience will guide how you manage your project and help you figure out where to say yes (and no!). + +In this section, we’ll help you think through a few important questions around the goals of your project. + +## Define your goals + +Let’s start by defining your goals. Simply put: *why are you open sourcing this project?* + +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: + +* An individual wants to show off his or her portfolio +* An individual or company wants others to use what they’ve created +* A community wants to find collaborators to shape the project and help it grow +* An individual wants to get feedback on their work +* A company wants make their code transparent + +## Figure out what you need from others + +Once you’ve listed out your goals, ask yourself: *for each of these goals, what do I (or we) need from others?* + +For example, if you are open sourcing a project to build your portfolio, you may not be actively looking for contributions, or you don’t have time to review them. In that case, you might clearly state in your README that you are not accepting contributions. + +**(add an example, e.g.: https://github.com/infinite-scroll/infinite-scroll or https://github.com/dboehmer/hotelres)** + +On the other hand, if you are building a community project, you may be very actively looking for contributors. In this case, you might want to be more detailed about the types of contributions you’re looking for and explicitly give your readers permission to modify and shape the project. + +**(add an example, e.g. https://github.com/Level/levelup#contributing)** + +If you’re hoping to get feedback on something you’ve created, consider asking for the type of feedback you’re looking for, whether it’s general code review or help with a specific bug. + +**(add an example, e.g.: https://github.com/alexreisner/geocoder#known-issue)** + +## 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. + +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!) + +The needs of your users affect every part of your project, from functionality to customer support to [branding](branding.md). + +Here are some questions to consider early on. If you don’t know the answers, consider how you might be able to figure them out (for example, polling others online or reading through forums where your users might congregate). + +* Does the project’s name resonate with my audience? Will they remember it or think it is clever? +* What are the skills and background of my audience? Do they need to know anything special about how to use my project? +* Where might my users feel frustrated? Can I (or we) make it easier somehow? +* Will my users need extra help or support anywhere? +* How does this project compare to other projects that my audience might be familiar with? + +## Save your answers, you’ll need them! + +Congratulations, you just did your first round of user research for your project! If you wrote down the answers to the above questions, save them for later. You can reference your goals and expectations as you develop your project. + +We’ll use these answers in the next section, as you consider the brand of your project. + +## Related content + +(add some related content here) + +[Previous](index.md) | [Next](branding.md) diff --git a/_content/index.md b/_content/index.md new file mode 100644 index 00000000000..3f62a5a5081 --- /dev/null +++ b/_content/index.md @@ -0,0 +1,9 @@ +# Welcome + +Welcome to the Open Source Handbook! We created this handbook to help creators like you successfully release and grow your projects. + +We wrote this handbook based on what we’ve learned from watching millions of open source projects on GitHub’s platform. Whether you’re an individual, a company, or a community, you’ll find plenty of real stories and experiences in this handbook to guide you. + +Special thanks to for their valuable input in the initial release of this handbook. If you’d like to contribute, head on over to to get started! + +[Next](getting-started/index.md) From 546854b721e1cfbec8e30a82252eb8b5e68387b0 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Fri, 22 Jul 2016 23:24:32 -0400 Subject: [PATCH 2/6] Link to content in README --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index c54e474bf7f..29e9ef100eb 100644 --- a/README.md +++ b/README.md @@ -4,6 +4,8 @@ This handbook is a collection of resources to help individual, communities, and This handbook aims to foster healthy open source communities, and provide a canonical place for the community to discuss and codify best practices into highly-approachable resources. +### [Get Started](_content/index.md) + ## Contributing This handbook aims to reflect community best practices. Check out [CONTRIBUTING.md](/CONTRIBUTING.md) for ways to offer feedback and contribute. From 8c391cfad76a67427f443bd546445215b02d3832 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Fri, 22 Jul 2016 23:32:43 -0400 Subject: [PATCH 3/6] Fix blockquote --- _content/getting-started/branding.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_content/getting-started/branding.md b/_content/getting-started/branding.md index 9f886b72979..d7ede408753 100644 --- a/_content/getting-started/branding.md +++ b/_content/getting-started/branding.md @@ -28,11 +28,11 @@ Throughout the life of your project, you’ll do a lot of writing: READMEs, tuto [@janl](https://github.com/janl) discovered that the way he spoke to others helped create a positive brand for [CouchDB](https://github.com/apache/couchdb): -*When I started out at CouchDB and we finally joined the ASF and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.* +> When I started out at CouchDB and we finally joined the ASF and it was standard procedure to have a user@ mailing list for end-user support, I remembered my days in the #php channel and decided that that’s not the culture I want to have there. So for the first three or so years, I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style. +> +> My responsibilities since have shifted quite a bit and I’m no longer checking on the user@ mailing list day-to-day, but every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud. -*My responsibilities since have shifted quite a bit and I’m no longer checking on the user@ mailing list day-to-day, but every time I join and read, I see the culture that I helped plant there seven years ago and it makes me very proud.* - -[http://writing.jan.io/2015/11/20/sustainable-open-source.html](http://writing.jan.io/2015/11/20/sustainable-open-source.html) * * +http://writing.jan.io/2015/11/20/sustainable-open-source.html Beyond how you write words, your coding style may also become part of your project’s brand. For example, [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](http://contribute.jquery.org/style-guide/js/) are two projects with rigorous coding styles and guidelines. From 5f48e1d61522171b96c521099ef81080adf2d45f Mon Sep 17 00:00:00 2001 From: Nadia Eghbal Date: Mon, 25 Jul 2016 10:55:23 -0700 Subject: [PATCH 4/6] added related content link to Mozilla WOW personas workshop --- _content/getting-started/setting-expectations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_content/getting-started/setting-expectations.md b/_content/getting-started/setting-expectations.md index ad2177de88a..b53e1025847 100644 --- a/_content/getting-started/setting-expectations.md +++ b/_content/getting-started/setting-expectations.md @@ -58,6 +58,6 @@ We’ll use these answers in the next section, as you consider the brand of your ## Related content -(add some related content here) +* http://mozillascience.github.io/working-open-workshop/personas_pathways/ [Previous](index.md) | [Next](branding.md) From 9f35778fef39e9a7b15e347c7f9a4aa4b1a82dea Mon Sep 17 00:00:00 2001 From: Nadia Eghbal Date: Mon, 25 Jul 2016 10:57:02 -0700 Subject: [PATCH 5/6] added related content link added Mozilla's WOW contributing guide workshop to links --- _content/getting-started/preparing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_content/getting-started/preparing.md b/_content/getting-started/preparing.md index acfe04528be..e6c51d1e605 100644 --- a/_content/getting-started/preparing.md +++ b/_content/getting-started/preparing.md @@ -92,6 +92,7 @@ Launching your project is only the first step. If you’re looking for feedback * [https://github.com/blog/1184-contributing-guidelines](https://github.com/blog/1184-contributing-guidelines) * [http://www.contribution-guide.org/](http://www.contribution-guide.org/) * [https://github.com/nayafia/contributing-template](https://github.com/nayafia/contributing-template) + * [http://mozillascience.github.io/working-open-workshop/contributing/](http://mozillascience.github.io/working-open-workshop/contributing/) * Codes of conduct * [http://contributor-covenant.org/](http://contributor-covenant.org/) * [https://github.com/django/code-of-conduct](https://github.com/django/code-of-conduct) From e15fbe74cb132c484d5ec71ea504a15a72bdfb77 Mon Sep 17 00:00:00 2001 From: Brandon Keepers Date: Mon, 25 Jul 2016 14:59:42 -0400 Subject: [PATCH 6/6] Clean up links from GDocs export --- _content/getting-started/branding.md | 8 +++---- _content/getting-started/preparing.md | 30 +++++++++++++-------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/_content/getting-started/branding.md b/_content/getting-started/branding.md index d7ede408753..c97cdca0413 100644 --- a/_content/getting-started/branding.md +++ b/_content/getting-started/branding.md @@ -14,11 +14,11 @@ Puns are fun, but remember that some jokes might not translate to other cultures ## Namespace 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](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 -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/](http://ivantomic.com/projects/ospnc/) +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/ -Consider whether you’ll want a website, Twitter handle, or other properties to represent your project. If so, make sure you can get the names you want. Ideally, reserve those names now so you have peace of mind. You can check for domain name availability here: [https://instantdomainsearch.com/](https://instantdomainsearch.com/) +Consider whether you’ll want a website, Twitter handle, or other properties to represent your project. If so, make sure you can get the names you want. Ideally, reserve those names now so you have peace of mind. You can check for domain name availability here: https://instantdomainsearch.com/ Finally, it doesn’t hurt to do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn’t want them to see? @@ -42,6 +42,6 @@ We’re almost there! Next, we’ll walk you through a few components that every ## Related Content -* [http://producingoss.com/en/getting-started.html#choosing-a-name](http://producingoss.com/en/getting-started.html#choosing-a-name) +* http://producingoss.com/en/getting-started.html#choosing-a-name [Previous](setting-expecations.md) | [Next](preparing.md) diff --git a/_content/getting-started/preparing.md b/_content/getting-started/preparing.md index e6c51d1e605..16e5b88ab25 100644 --- a/_content/getting-started/preparing.md +++ b/_content/getting-started/preparing.md @@ -24,7 +24,7 @@ There are [over 70 approved licenses](https://opensource.org/licenses/alphabetic * [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 [http://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. (Different licenses carry slightly different permissions. You can use http://choosealicense.com to find the right license for you.) (include image of license selection on GitHub new repo here?) @@ -80,20 +80,20 @@ Launching your project is only the first step. If you’re looking for feedback ## Related content * Licenses - * [https://github.com/blog/1530-choosing-an-open-source-license](https://github.com/blog/1530-choosing-an-open-source-license) - * [http://choosealicense.com](http://choosealicense.com) + * https://github.com/blog/1530-choosing-an-open-source-license + * http://choosealicense.com * READMEs - * [http://tom.preston-werner.com/2010/08/23/readme-driven-development.html](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) - * [https://github.com/matiassingers/awesome-readme](https://github.com/matiassingers/awesome-readme) - * [https://pages.18f.gov/open-source-guide/making-readmes-readable/](https://pages.18f.gov/open-source-guide/making-readmes-readable/) - * [https://changelog.com/a-beginners-guide-to-creating-a-readme/](https://changelog.com/a-beginners-guide-to-creating-a-readme/) - * [https://gist.github.com/jxson/1784669](https://gist.github.com/jxson/1784669) + * http://tom.preston-werner.com/2010/08/23/readme-driven-development.html + * https://github.com/matiassingers/awesome-readme + * https://pages.18f.gov/open-source-guide/making-readmes-readable/ + * https://changelog.com/a-beginners-guide-to-creating-a-readme/ + * https://gist.github.com/jxson/1784669 * Contributing guides - * [https://github.com/blog/1184-contributing-guidelines](https://github.com/blog/1184-contributing-guidelines) - * [http://www.contribution-guide.org/](http://www.contribution-guide.org/) - * [https://github.com/nayafia/contributing-template](https://github.com/nayafia/contributing-template) - * [http://mozillascience.github.io/working-open-workshop/contributing/](http://mozillascience.github.io/working-open-workshop/contributing/) + * https://github.com/blog/1184-contributing-guidelines + * http://www.contribution-guide.org/ + * https://github.com/nayafia/contributing-template + * http://mozillascience.github.io/working-open-workshop/contributing/ * Codes of conduct - * [http://contributor-covenant.org/](http://contributor-covenant.org/) - * [https://github.com/django/code-of-conduct](https://github.com/django/code-of-conduct) - * [https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/](https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/) + * http://contributor-covenant.org/ + * https://github.com/django/code-of-conduct + * https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/