How to Opensource a Project
- Open-sourcing a hardware project means creating public documentation to which anyone can contribute to build upon existing work. This starts with publishing any existing designs openly on the internet. In practice:
- Creating a public repository where you upload your designs and documentation. This could be a wiki, a website, or GitLab. You can use existing platforms such as the OSE wiki, Appropedia, or others.
- Allowing the use of your designs and documentation for any purpose, including selling the finished product. See 4 Freedoms of Open Hardware. This terms are declared in a license.
- Declaring or creating a license - which shows the terms under which your documentation must be shared. This license should be clearly visible in the public face of the project.
- Developing a contributor community - making it easy for others to download, study, modify, and share improvements. Creating a public repository such as a wiki, website, or GitHub/Gitlab. Setting up a communication platform, such as public forums onDiscourse, an email list, or other project management, for communication purposes. Clear contributor guidelines and communication channels are key, and license clarity allows anyone to understand whether a project is open source - or proprietary.
- Understanding that any documentation license that is non-commercial is not open source
- For advanced collaboration - study how to engage in Open Source Product Development
The general guidelines is to use commmonly available toolchains and workflows where these are open source and easy to access for widespread collaboration. As opposed to proprietary toolchains, which others cannot easily access, and where file formats may not be universal. Since open source hardware digital design is done in CAD software, the best practice is to use the premium open source CAD design packages such as FreeCAD or Blender. KiCad can be used for electronics, and many others.
- For hardware - certify your finished product with OSHWA - https://certification.oshwa.org/basics.html
- Best practices for software - 
- Levels of Openness - much more in-depth analysis of what open collaboration really means, and the shortcomings preventing transparent collaboration from happening