Add foss checklist post

site/content/posts/open-sourcing-checklist.md

+title: Open Sourcing Checklist
+date: 2023-05-19
+indeximage: /uploads/2023/05/we will open source it later.png
+indexalt: "Write a horror story for your industry using just four words."  "We'll open source it later"  Text is from a Twitter screenshot at https://twitter.com/jamesvasile/status/1410241468833406986
+
+Taking an existing, non-open codebase into the open is one of those tasks that seems relatively simple --- apply open source license and publish the code.  In practice, however, there is some hidden complexity along the way, and many projects start out with the best of intentions but fail to complete the process.
+
+This, of course, is why we always advise people to [be open from day one](/2018/09/be-open-from-day-one/).
+
+[
+!["Write a horror story for your industry using just four words."  "We'll open source it later"  Text is from a Twitter screenshot at https://twitter.com/jamesvasile/status/1410241468833406986](/uploads/2023/05/we will open source it later.png)
+](https://twitter.com/jamesvasile/status/1410241468833406986)
+
+
+This document is a checklist of steps you might take before you finally publish your work under open source license.  Most steps are optional, but all of them have value.  Think of them as best practices, not mandatory requirements.  Consider each step and whether it applies to your project.  Then narrow the checklist to the steps you will take.  Feel free to do these in any order that makes sense to you.  Good luck, and please ping us at info AT opentechstrategies.com if we can help.
+
+This document is not an exhaustive list of concerns you should consider when open sourcing.  It doesn't go into the reasons why you are considering open source (and we have found that going open with a clear goal in mind usually fails to achieve any goals at all).  It doesn't include building a community or a sustainability model (open source is not, in and of itself, a business model).  All of those are considerations of a much bigger picture than this checklist contemplates.
+
+
+**[ ] Check your copyrights.**  Ensure you have the needed permissions to release your project under open license.  These permissions could come from licenses or copyright ownership. Do not assume you have the rights. Go look. Do an audit.  If necessary, read up on works for hire and federal ownership of copyright.
+
+
+**[ ] Consider your patent portfolio.**  FOSS licenses sometimes include patent permissions, whether explicitly stated or implicitly granted.  If you or your contributors hold patents, you should evaluate the impact of open licensing on your patent rights.  You might decide your patents are best used to nurture your open source strategy.  Alternatively, you might want to take steps to protect your patents.
+
+**[ ] Pick an outbound license.**  Usually this will be BSD, Apache, or some flavor of GPL, but there is a wide range of [FOSS licenses](https://opensource.org/licenses/) out there for you to choose from.
+
+**[ ] Consider an inbound license.**  Sometimes these licenses are called
+"contributor license agreements".  By default, a project usually takes code
+under an inbound license that is equal to their outbound license.  If that
+outbound license gives the project all the rights it needs for the foreseeable
+future, that's good enough. If it doesn't, you might consider a contributor
+license agreement.  Project Harmony has some [sample
+agreements](https://harmonyagreements.org/) that are old but worth reading (full
+disclosure: James Vasile worked on that project).
+
+**[ ] Ensure license compatibility with dependencies.**  Two pieces of software are license compatible when they can be combined into one work and released together without violating the licenses of either of the original pieces of software.  The combined work is then treated as goverend by only one of those two licenses, usually the less permissive license.
+
+
+**[ ] Upload your code to an online repository.**  This will probably be a git
+repository hosted on [GitHub](https://github.com), [LibreHQ](https://code.librehq.com), or a
+[GitLab](https://gitlab.com) instance.  *Do not make it public it yet.*
+
+**[ ] Add a README.md file.**  Place it in the root directory of your repository.  It should specify the name of the software and describe what it does in lay terms.  Include contact information, directions to your mailing list or Zulip/Slack /Discord instance, and your general level of willingness to accept public participation.  Provide basic instructions for installation or refer readers to online documentation.
+
+**[ ] Test installation.**  Give repo access to a new user or developer who has never installed your software before.  Have them follow your instructions.  If they got a running installation, good.  If not, fix your instructions before you publish.
+
+
+**[ ] Fix your test suite.**  Ensure your tests pass.  Sideline (e.g. mark "expected fail") those that don't.  New users will often run tests to make sure their install worked.  If the tests fail, it will be difficult for them to know whether that is because the install failed or because that test stopped passing and nobody cared.
+
+**[ ] Add a LICENSE or COPYING file.**
+
+**[ ] Add a CONTRIBUTING file.**  This file tells people how to contribute.
+
+
+**[ ] Prepare for public participation.**  Pay particular attention
+to your planned cadence of replies to incoming interest.  Your approach to
+inbound messages will, of course, depends on your community strategy, which is
+beyond the scope of this checklist (see our [Archetypes
+Analysis](https://opentechstrategies.com/archetypes) and [Producing
+OSS](https://producingoss.com/) for starting points).  Document that approach in
+your README or CONTRIBUTING file so people can form expectations about how
+quickly you will respond to issues and PRs.  See
+
+
+**[ ] Add issue templates.**  These can help guide public participation.  Give people some hints about *where* discussion of issues happens.  Typically, public projects default to the issue tracker, but some prefer the project's mailing list or forum.
+
+**[ ] Examine ownership of your repository.**  Make sure multiple people have authority and actual ability to administer the repository.
+
+
+**[ ] Squash history.**  Does your repository contain sensitive information or secrets?  Has it ever?  When repositories are private, people tend to be less guarded about what they check in to the repo.  Problematic content includes secrets and PII but also might include commit messages containing profanity or even defamatory content.  It is not practical for most projects to examine all their history, so many delete, edit, or squash history before going public.
+
+**[ ] Publish documentation.**  Centralize it into an accessible location under open source or creative commons license.  Documentation should be open to change requests.  Track down the design and usage documentation that may currently reside in various internal places and make them public.  Collect the implicit learnings of your team, and write them down so people without your experience can productively approach the software.
+
+
+