OWi Open Source It Manual EN

OWi Open Source It Manual Vs 1.2

/* zur deutschen Version */

How to open source your hardware-design (in short) :

1   Publish – all data about your design like the building plans, the source-files, the bill of materials, the software source code etc. in order to enable others to understand, modify and build your design and to collaborate on it with you.

2   Open Formats – use wherever possible data-formats that others can easily view, copy and edit. Prefer open formats and open design tools or at least cheap and accessible alternatives.

3   Use a free culture license – publish everything under a free culture license for example the Creative Commons Attribution License. That gives others the legal rights to work with your files and build upon it openly.

4   Choice of parts – use wherever possible in your design readily-available components and materials as well as standard processes, open infrastructures and unrestricted content. This maximizes the ability of others to make and use hardware.

5   Spread it – mark your files prominently as open-source hardware (for example by using the open source hardware logo or link to this manual). Make your work easy to find online and promote it.

-

Long Version:

-

OWi Open Source It Manual Vs 1.2

(This is a nonprofessional translation of the OWi Open Source it Manual from the german original. Please excuse the quality. If you like to help to make it better please don’t hesitate to contact us.)

PDF Download (Vs.1.1)

Open Source is a contribution and attempt towards a more innovative,  more social and economical sustainable economy. Become a part, join the progress. Open source your product, design, project or process. This manual shares suggestions and basis assumptions for this: How to open source your hardware? This is the version number 1.2 of the manual. New versions will be published with a unique version number.

1. Publish source files

(1.1)     Sharing Files. Publishing source-files and information about hardware and hardware related processes is the core practice of Open Source Hardware. The publication should happen in a way, that allows and enables everybody to study the information, modify it, (re)distribute it and to build the hardware and do all of this in a commercial way if wanted. (compare the Open Source Hardware Definition and Statement of Principles.)

(1.2)     Freedom. Open Source Hardware is basically about freedom for knowledge and people. Therein lies the power of Open Source. The greater the openness and freedom of the information is the stronger becomes Open Source. Five things determine the openness and freedom of the information given by someone: the software-tools that were used to create the source-files, the license they are under, the design of the described objects or processes himself, the quality in structure of the files and information and the findability or connectedness of the information. On each you will find information by further reading this manual.

2. Software-tools and data-formats

(2.1)    Free tools and data formats. Use data formats that can easily be read and modified by everybody because the software to do this is free and accessible. Open data formats and tools should be preferred. If this is not possible use cheap and easy to get alternatives.

(2.2)    Modifiability. Publish your information in formats that make modification possible and easy. The original design files are probably the best choice.

(2.3)    Convertibility. Chose whenever possible formats that are easy to convert into other formats.

(2.4)    Portability. Make your information available in a way that makes it easy to copy them, transmit them and republish (mirror) them someplace else.

(2.5)    Platform-independency. A simple and summing up measure for the freedom of tools, the modifiability, the convertability and the portability is „platform-independency“. Try to publish your information in a way that they are as far as possible indpendent from a certain publication format or publication place but ready to cross borders. The freedom and openness of the information comes true when it is transferred between different websites, platforms, servers, carriers and formats. Freedom as teached in this manual. Freedom is the best platform!

(2.6)    Collaboration. We know that the available tools and techniques for open documentation, communication and collaborative development of hardware and processes are not in an optimal stage nowadays. Help to make them better: Play with new ideas, give them a chance and test. Keep this manual in mind and search for ideas and ways that give you extended control. The manual itself does not recommend certain platforms or formats. But you will probably find lists with links and hinds somewhere around.

(Update: There is a collection of links here now.)

3. Licensing

(3.1)    Use a free culture licence. Use a free culture licence to make your design open. This is a fundamental step for open collaboration. Licences tell something about rights of use. With a free culture licence you give people rights to work with your design files in the public what would not be allowed without a license. Note that copyright (on which most licenses are based) doesn’t apply to hardware itself, only to the design files for it – and, then, only to the elements which constitute “original works of authorship” (in U.S. law) and not the underlying functionality or ideas. Therefore, it’s not entirely clear exactly which legal protections are or aren’t afforded by the use of a copyright-based license for hardware design files.

(Update: There is a License Guide now with more information about this and licensing at all.)

(3.2)    Choosing a licence. There are different licenses out there. Make sure to choose one that grants all the freedoms mentioned here under 1.2 and by the Open Source Hardware Definition and Statement of Principles. In general one can say that a licence enables the more openness and freedom the less limitations and conditions it contains. The area of licences is in constant development. Current examples of suiting licences are:

a.    the Creative Commons Attribution Lizenz (CC-BY),
b.    the Creative Commons Attribution-ShareAlike Lizenz (CC-BY-SA),
c.    the GNU General Public Licence (GPL),
d.    the TAPR OHL,
e.    the CERN OHL and
f.     the FreeBSD Licence.
g.    the CC0 Universal – Public Domain Dedication

(3.3)    Licence remark. Put the licence remark prominent on all your design files and web pages. Everybody should be able to find it immediately. Prominent placed open licence remarks are an ambassador for openness and a multiplier of your open source intentions.

(3.4)    Follow the licence. If you build upon the work of others watch carefully that you meet all the requirements of their licence. Take your time for the attribution and chose a prominent spot for it. This builds trust, collaboration and pushes the development of an open source culture.

4. The design of the object itself

(4.1)    Availability of components and materials. Use in your design wherever possible readily-available components and materials (easy to find and to buy), standard processes, open infrastructure and unrestricted content. Where this is not possible give hinds how and where to get things or how to substitute them.

(4.2)    Understandable structure. Create the design in a way that it is clear and easy to understand for someone else. Use widely known standards. Ease of repair could be a good design ideal as well. Is it easy to debug, is it easy to dismantle, are single components and parts replaceable?

(4.3)    Standards. Try to make sure that the construction only needs tools and processes that are generally available, cheap to buy or easy to set up. Use standards wherever possible. Where this is not possible give hinds where to get special tools or how to set everything up step by step.

(4.4)    Version number. Label the product with a version number or release date so that people can match the physical object with the corresponding version of its design files.

5. The design of the information

(5.1)    Understandable information. Try to make your design files easy for someone else to understand. Organize them in a logical way; use an easy language, avoid exotic information-designs and use instead common and easy to create things like photos, charts, lists, headlines etc.

(5.2)    Overview/Introduction. If the thing is complex, your open-source project should include a general description of the hardware’s identity and purpose, written as much as possible for a general audience. That is, explain what the project is and what it’s for before you get into the technical details. Add a good photo or rendering if you have one.

(5.3)    Bill of materials. Provide a separate bill of materials. Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part. Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places.

6. findability or connectedness

(6.1)    Spreading and connecting. In order to make the openness of your product or project work best you need to make sure, that others can and will find it. Finding information is the first step to an interconnected learning and collaboration process. There are a lot of things you can do for this, technical as well as social things. This manual can’t cover them all. But these hints are for sure a good start:

a.    Advertize. Advertize your project, use the web and social media to do it. Talk to people.
b.    Make the information easy to find on your webpages and put a link on the product or the package and your broshures etc.
c.    Read something about Search Engine Optimization. Use the right words; what would people search the web for etc.
d.    Study other open source projects and contact them if they inspire you.
e.    Experiment! Test new networking techniques: >> This manual has an offer for an networking-experiment as well: Link to the manual from your pages. Linking to the manual is a good way to show others how your project and open source in general works. And by that they also learn how to create their own open source project tomorrow. A good place for the link could be right next to your licence remark. You can download a button for this below and also copy some html for your page.

April 2014

<>

Embed Code

osimlg 46x84  86x46px

<a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/"><img alt="Open Source It Manual" style="border-width:0" src="http://owiowi.net/wp-content/uploads/2014/06/osimlg-46x84.png" /></a><br /><a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/">Open Source It Manual</a>

osimlg 102x56 102x56px

<a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/"><img alt="Open Source It Manual" style="border-width:0" src="http://owiowi.net/wp-content/uploads/2014/06/osimlg-102x56.png" /></a><br /><a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/">Open Source It Manual</a>

osimlg 76x138 138x76px

<a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/"><img alt="Open Source It Manual" style="border-width:0" src="http://owiowi.net/wp-content/uploads/2014/06/osimlg-76x138.png" /></a><br /><a rel="open source it manual" href="http://owiowi.net/open-source-it-manual-english/">Open Source It Manual</a>

CLICK here for different colors, sizes and the vector file

Earlier versions of the Manual: Vs 1.0 (Nov. 13)Vs 1.1 (Jan. 14)

Spread the word, share it

6 Gedanken zu „OWi Open Source It Manual EN

  1. ptroxler

    “Use a licence” is pragmatically OK,
    Strictly speaking it is nonsense. You can only license rights you have — see the 2nd white paper by Michael Weinberg / PublicKnowledge, page 20: “I can offer you a license to paint the Brooklyn Bridge pink, but since I do not own the Brooklyn Bridge the license will not be of much help when you are arrested for vandalism.” (http://publicknowledge.org/files/What%27s%20the%20Deal%20with%20Copyright_%20Final%20version2.pdf)
    I thin we should include this fact at least in a footnote.

    Antworten
  2. Lars Artikelautor

    Could adding something like „Use a license for your work“ or maybe „With a licence you give people rights – to do with your work – that they would not have without the licence.“ do the job? Simply make somehow clear, that you can use a license only for things that are your work, because for those you own the copyright? And when i create a file, a desrciption, a blue-print or whatever i do own the copyright for it? Right?

    Antworten
  3. John

    Hey,
    the OSHW definition says:

    „Ideally, open hardware uses … open infrastructure, unrestricted content … to maximize the ability of individuals to make and use hardware.“

    I think we should add this, at least the open infrastructure.

    OSHW definition: http://www.oshwa.org/definition/

    Antworten
  4. Pingback: OS design | Pearltrees

  5. Wouter Tebbens

    It would be good to mention the differences between copyleft and non-copyleft licenses. Copyleft obliges the derivative works to stay under the same license, and thus helps to strengthen the community. Non-copyleft free licenses allow derivative works to be published under any conditions and favour the individual interesting in his own personal benefits. That’s the main difference between CC-BY-SA and CC-BY.

    Antworten

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>