UPDATE: The deadline has been extended one week to 02-18.
As we get approach the 2021 Open Hardware Summit on April 9th, we are now soliciting talk proposals from interested speakers. This year’s summit is virtual and will be held online on Friday 2021-04-09, 9:00 AM – 5:30 PM EDT.
The Open Hardware Summit is for presenting, discussing, and learning about open hardware of all kinds. The summit examines open hardware applications, practices, and theory, ranging from environmental sensors to 3D printable medical devices to open hardware processors and beyond. We are interested in open hardware on its own as well as in relation to topics such as software, design, business, law, and education. Past talks have featured topics such as advances in space propulsion, humanitarian projects, right to repair legislation, open hardware in education, and open hardware marketing.
For our eleventh edition we are especially looking for speakers who can offer insights around the role of open hardware in the COVID-19 pandemic, open hardware medical devices, and related topics.
We invite talk proposals from individuals and groups. Find all the details over at the summit site. Submissions are due by Thursday 2021-02-11 at 11 PM EDT.
The 2021 Open Hardware summit will be held online again, Friday April 9, 2021. Just like this year, the summit will be livestreamed, but ticket holders will have access to additional interactive portions of the summit like meet-and-greets, workshops, and sponsor booths.
Find details, including ticket and sponsorship information at 2021.oshwa.org. We look forward to seeing you (in the chat) then!
October is right around the corner, which means it’s time to get ready for Open Hardware Month! This year with our theme of Label and Certify we’re putting the spotlight on two ways to help the world know your hardware is Open Source: Open Hardware Facts and the OSHWA Certification.
Open Hardware Facts
Inspired by our Executive Director Alicia Gibb, and created by board member Jeffrey Yoo Warren, the Open Hardware Facts Generator helps you declare the licenses used in your project using a format similar to the US Nutrition Facts Label. Listing your licenses in one prominent place (such as the README of your repository) helps users immediately know what they can and can’t do with your source, rather than having to browse through individual files.
OSHWA Certification
The OSHWA Certification continues to grow, with almost 1,000 projects from over 40 countries! If you’re not yet familiar, the certification program provides a way for consumers to immediately recognize hardware whose meaning of “Open” conforms to the OSHW Definition. It also provides a directory for OSHW creators, which stands as evidence that your product is in compliance with the OSHW Definition.
Update on OHM Events
We originally planned to have the community host virtual events this year, but we found many people are not looking forward to another video meeting. Therefore, we are shifting our focus to just labeling, certifying, and documenting projects from home. We look forward to normal OHM events in 2021!
Hosting and Joining OHM Events
We invite individuals and companies alike to host events relating to the theme, or supporting Open Hardware more generally. Unlike previous years, we expect most events to be virtual due to COVID-19. Thankfully, both labeling and certifying can be done from home! If you choose to host an in-person event, we expect you to follow all local health guidelines to help keep our community safe. Find what you need to plan an OHM event at the OHM website.
Looking for an OHM event to join? As events are submitted and approved, they’ll be listed on the OHM website as well. For virtual events, we’ll also list the online platform being used and the event’s time zone.
The Ada Lovelace Fellowship encourages women, LGBTA+, and/or other minorities in the open technology movement to both participate and nurture an incredible, diverse community within open source.
For the fifth year running, we are ecstatic to offer TEN (10) Open Hardware Fellowships to members of the community. This includes travel assistance and entrance to the 2017 open Hardware Summit!
We are at an exciting point in time for open source and hope to encourage everyone, no matter their walk in life, to embrace and participate in this incredible movement!
The Open Source Hardware Association, a 501(c)3 non-profit, is excited to announce the 2017 Open Hardware Summit taking place October 5th, 2017 in Denver, Colorado. This is the annual gathering of the OSHWA organization and open hardware community. Through the Open Hardware Summit, we aim to create an inclusive welcoming environment to empower people in all stages of discovering open source technology.
The Open Hardware Summit is where anyone and everyone can participate and collaborate in the open source community!
At this time we are opening the call for companies or individuals interested in sponsoring this year’s summit. More information can be found here.
For the fifth year running, we are ecstatic to offer up TEN (10) Open Hardware Fellowships to members of the community. This includes travel assistance and entrance to the 2017 open Hardware Summit!
The Ada Lovelace Fellowship encourages women, LGBTA+, and/or other minorities in the open technology movement to both participate and nurture an incredible, diverse community within open source.
Looking for other ways to are other options to support and participate in the movement? You can help by:
Sharing information on individual and corporate memberships with friends and colleagues
Participating on social media outlets (like Twitter and Facebook) to keep the conversation going and spread news of the summit
Last, but far from least, donating to our 501(c)3 (be sure to remember that some companies match gift amounts their employees make to a non-profit! This doubles the distance that gifts will go!!)
Later on this May, OSHWA will be leading a Session at the Upcoming OuiShare Fest in paris.
OuiShare Fest is a conference about the collaborative economy that will feature sessions ranging from cooperatives to shared mobility, from p2p travel to collaborative finance, from Open Value Networks to Open Source Hardware and more. As I’m also being OuiShare Fest program fellow, I really thought this was an amazing opportunity to connect with the European community. Indeed OuiShare Fest has many amazing open source hardware projects featured such as Open Source Beehives, P2P Food Lab, OSVehicle and more.
Addieand I will participate and co-moderate a session that will be dedicated to potential solutions to scale OSHWA impact and, in general, awareness on the Open Source Hardware topic in Europe.
For this occasion, we are also releasing with you for the first version of the OSHWA BRANCHING CHAPTER: there you can find the vision and the duties when creating an OSHWA branch in your city or country.
We basically require three members to kick off a branch that puts together some community engagement and education program.
At the OuiShare Fest we will likely announce the formation of the first three or more new European branches (Italy, The Netherlands, Germany, Spain and France are already working on it) so we really look forward to get your feedback and see if we can finally be able to announce more, or just put you in touch with the upcoming branch leaders.
If you’re interested to join OuiShare Fest we have a special – limited number – 20% discount for OSHWA community that you can ask by getting in touch directly with me (mail to Simone at Ouishare dot net)!
Finally! I’m able to followup after the First Open Source Hardware Documentation Jam!
As many of you might know, at the end of April, I’ve been the facilitator of a Jam in New York city: it was the First Open Source Hardware Documentation Jam – OSHW Doc Jam (see http://www.opensourcewarehouse.org/ for details): the event has been sustained by many Sponsors and Supporters and OSHWA supported the event from the beginning.
We held the event with the objective to start a fruitful discussion about how to share moredocumentation regarding Open Source Hardware projects.
We had almost 40 people working along the three days to think about possible strategies and solutions, prototype (some times) and sharing them with the public in real time.
Two parallel Jams in Berlin and Amsterdam were held and we are now opensourcing the format to share the lesson we learnt and allow others to use this format for this or other application fields.
I just want to give you a short comment on the content we discussed, even if the oshwa will be following up in the next weeks with the discussion (we are thinking to use public hangouts, and Social Media. There are a bunch of good places online to discuss about open hardware and we will be posting the news there (eg: OSHWA mailing list, Ouishare Factory Facebook Group, The Open Manufacturing google group, etc…)
My mission as Int’l Branches Chair here at OSHWA is to help OSHWA grow internationally: I’ve also created this Facebook group called Open Source Hardware Communityhttps://www.facebook.com/groups/194351110718598/ to trigger a contextual discussion on building a stronger OSHW community of users and creators worldwide so…please join!
The Results
Coming back to the Jam; let’s focus a little bit on the documentation we are releasing today. The discussion at the Jam was mainly related to three separate threads:
1) Standardization: Having a more interchangeable format, a shared information *standard*, and interconnected data among the different portals, platforms, companies and projects producing and/or hosting OSHW documentation
2) Experience: Identify user experience issues, challenges and gaps in the documenting process so that we can create tools that make documentation creation easier
3) Movement / Organization: mostly related to how to replicate the event in itself and create more handy, easy to replicate formats.
We had actually run nine sessions as follows
Standardization
Remixing Derivatives Versions Components
Websites Interoperability
Taxonomy and Standards
Experience:
How to document your project while building
OSHW // OSS Parallels
Connecting Makers Socially
Accessibility of documentation
Movement / Organization
How to replicate the JAM
Ideas to create a Documentation Sprint
It’s not the objective of this post to going deep in the content since the discussion just started and we’ll keep you informed about the next steps and how to join. Here at this link you can find all the documentation available in a google docs directory https://drive.google.com/#folders/0BwJSOhVDu4bQSU1hZkhUc0cyMms. A zip file is also available. All documentaion is released in CC-BY. This will be hugely useful to anyone moving her steps in the OSHW industry with a product, a startup or even just a passion
Please get back to us for any comment or feedback!
How to organize a Jam Based on Open Space Technology (as implemented for the First Open Source Hardware Documentation Jam – OSHW Doc Jam, held in NY 26 to 28 of April 2013)
How to organize a Jam Based on Open Space Technology (as implemented for the First Open Source Hardware Documentation Jam – OSHW Doc Jam, held in NY 26 to 28 of April 2013)
Pre – event activities
Infrastructure
To create the communication infrastructure, we used a wordpress theme dedicated to events. More in details we used eventor theme. You should take into account that your website features:
A blog
A page for Sponsors (paying to support the budget)
A page for Partners (providing support, sending participants, other non strictly monetary suppor)
A page for the Agenda
A page for a bunch of hosts if any
Some lesson learnt:
keep the message clear and explain to the people what is all about
keep the message clear and explain to the people what is going to happen
Put an evident call to action in the homepage for registration
Advertising the Event
Materials needed
a PR kit with Event short description, Press contacts, Website, Host description, Event description, images to use. All should fit into one page.
a blueprint for an Invitation letter people can use to invite communities. Imagine this being posted on a forum, mailing list, etc…
A general text that you can use to explain about the event on emails/contact requests
Advertising the event is a bit tricky. Our strategy worked pretty well and was basically made of:
Posting the information in relevant message boards and mailing lists (we did for OSHWA, OKFN, etc…)
Ask for relevant blogs to cover the news
Search for local meetups that could be interested and send the information to the meetup organizers
Search for relevant people on Linkedin (or other social media) and contact them directly
Event Execution
The Production team: you should have a basic team of no less than three people if you’re aiming at an event of medium to big size (50-100 registered attendees). We used the Trello web application to keep track of the activities. Trello is a simple KanBan board. To get familiar with Agile methodologies and KanBan you can check wikipedia resources.
You should keep it simple for people that wants to join the team and contribute with the smaller effort possible (communication, recruit, logistics, others). This shall be the more open possible. We basically included anyone seriously willing to contribute. Even from remote. Their contribution was decisive for the event success.
How we included people? By providing them with access to the Trello board and by hosting alignment hangouts.
The main responsibilities / contributions of the production team are:
event design/adaptation
communication: help to create buzz, awareness, cover the news on blogs and journals
recruit: recruit people that could contribute with decisive contributions
logistics: help with the event organization (location, food, etc…)
Each of this contribution shall have an accountable person. The use of RACI Matrix is suggested.
The Inspiring Methodology
Our Jam format was inspired to the principles of Open Space Technology. En excellent review and links about the methodology are available on wikipedia and we suggest you to read about it http://en.wikipedia.org/wiki/Open-space_technology
How we actually implemented it
Our event spanned on three days, kicked off on Friday at 6 PM, closed on Sunday at 6 PM.
Setup
Session Proposals Wall: A piece of paper where you can hang proposed sessions (starting time – Ongoing/Closed)
Ongoing Sessions Wall: A piece of paper where you can hang sessions (starting time – Ongoing/Closed)
Closed Sessions Wall: A piece of paper where you can hang session reports in printed version
A prototyping table: A place that is dedicated to prototyping (may feature: Paper, Scissors, Cardboard, Colours, Big Sheets of paper, a 3D printer :), etc…)
Sessions move between the boards as they progress.
We had our personal interpretation of the format and we ended up with a mixed one with:
A first content focused phase in the form of short pitches. In our case it was about presenting initiatives dealing with OSHW Documentation. We planned it on Friday Evening
A second phase where we held the Open Space discussion with all participants in a circle and asked people to submit topics to the discussion. Each topic that was relevantly shared was picked as a Session Proposal
A short Session Agenda planning: we planned almost half of the proposed session session for saturday morning, afternoon or even sunday.
Here’s the detailed description of the phases
Start
Phase
Description and Activities
Friday 6 PM
Meetup
Welcome and Name Tags
Friday 6.30 PM
Meetup
The team introduces the background of the event and the resources we created.
Short Projects Presentations
Friday 7 PM
Tools and practices
A brief session about:
– Jam Methodology (OST)
– principles (such as session suggested duration, podcasting interviews, documenting)
– location facilities
– tools to use and best practices for documentation
is given by the hosts (short presentation)
Friday 7:10 PM
Meetup
We sit in a big circle of chairs
The host team will greet the people and briefly re-state the theme of the gathering.
All participants are invited identify issues or opportunities related to the theme and to their skills and ideas.
Participants willing to raise a topic will take the mike/stand and talk about the issue: people is encouraged to feedback.
At some point, the facilitator identifies the session, writes it on a sheet of paper and adds it to the proposals.
The session leader shall be identified at that very moment to enhance the possibility the session is actually run.
That person must make sure that a report of the discussion is done and posted on the Reports wall once the session is closed (so that any participant can access the content of the discussion at all times)
No limit exists on the number of items/sessions proposed.
We bring some drinks and some lite dinner snacks
A second open session is run, hoping that the discussion during the drink was fruitful
Before the event closure people are encouraged to gather around the proposal wall and discuss with the leaders. at the end of the day, every participant shall choose the session proposals she’s interested in joining from DAY2
Saturday 9:30 AM
Breakfast meeting and Ignite meetup
We serve breakfast there so that people meet and start to warm up
Saturday 10:00 AM
First Batch of Work: Solution Brainstorming
Session Leaders and interested folks gather around the proposal wall. As soon as a consistent interest is formed around a Session this session moves on Session Wall, picks a Table and moves on.
We shall encourage that sessions are kept under 2hrs: then the documentation is shared. Follow-up sessions can be re-scheduled obviously.
This process is reiterated continuously during the day, as long as a session closes people can join others in running sessions or propose/start other ones.
Putting a Session in the proposals leaves people the possibility to express interest so that after few sessions the leader (or someone else) could decide to kick off.
Saturday 12:30 PM
Reporting / Cross fertilization Session
Session Leaders are asked to give a 5 minute report of all the sessions they coordinated during the morning.
Saturday 1 PM
Lunch
Lunch is served: it stays there with not specific lunch time. Work continues in the Background
Saturday
7 PM
Reporting / Cross fertilization Session
Session Leaders are asked to give a 5 minute report of all the sessions they coordinated during the day.
Sunday 10:00 AM
Breakfast meeting and Ignite meetup
We serve breakfast there so that people meet and start to warm up
Sunday 10:00 AM
First Batch of Work: Solution Brainstorming
Repeating saturday kick off.
Saturday 12:30 PM
Reporting / Cross fertilization Session
Session Leaders are asked to give a 5 minute report of all the sessions they coordinated during the morning.
Sunday 1 PM
Lunch
Lunch is served: it stays there with not specific lunch time. Work continues in the Background
Sunday
5 PM
Reporting / Next steps focus session
Session Leaders are asked to give a 5 minute report of all the sessions they coordinated during the day.
A very special focus is requested in Followups/What’s next
Sunday
6/7 PM
Wrap up
Participants are left to wrap up for next steps, finalize documentation.
A common drink outside the venue is encouraged to slow down and say bye.
People can join or leave sessions at any moment. Sessions could be close or even cancelled at any moment. The session leader is responsible of the quality of the documentation.
Opting for only Digital Documentation
Even if the principles of OST asked for having documentation readily available in paper or visual format, ee opted for having only digital documentation.
We setup a Google Folder and created a Session brief Template to be used at each session kickoff.
Session Leaders were asked to
Create a folder named after the session, create a Session Brief copy for the session
Add documents in the session folder
We also kept an excel file with ongoing session information and links to the session folder.
Ticketing
We used Eventbrite for ticketing, we priced the event at 10$ just to lower the no show rate respect a free to attend event. A slightly higher price may have helped with budget and lowering no shows rate.
Video Documentation
Having a video operator to document the JAM will be a plus
Food
Food is very depending on your budget, style and everything. Our lesson learnt on food is that you tend to underestimate no show rate (we had a no show rate, decreasing from almost 30% on day 1, to almost 50/60% on day 3) and overestimate people appetite. Whatever are you planning to cater for, divide by a three at least.
Requirements for the Location
KEY Time availability – You need the location for all the event timespan plus 4/6 hours in advance
KEY Possibility to attach Paper Sheets on the wall with tape
KEY A plenary room for the number of people you are looking for (ideally a place where we you can put up to a number of tables for eight people in line with expected attendance – no show rate)
KEY Chairs for all
KEY A projector
NICE2HAVE Amplified mike
KEY Many Plugs and cables (each table shall have at least 5/6 plugs available)
KEY Good Wi-Fi Network connectivity
NICE2HAVE A dedicated space for Lunch (not on the working tables)
Materials to be provided
NICE2HAVE Whiteboards with whiteboard markers
KEY Few Sharpie magic markers for white sheets
KEY Few Large white sheets for creating the session walls
KEY Post Its
NICE2HAVE Few sets of Coloured markers
NICE2HAVE A printer available
KEY Drafting Tape
Target Composition of the attendance before the event
Before the event, we had an attendee number and composition target. Ideal target was to have 75 participants with a composition made of:
35% Stakeholders of open source hardware community (OSHWA, OSE, others).
We created separate tickets on eventbrite, asking people to pick one specific role and we made some relevant invites, especially from the open source hardware community and this helped having relevant insiders at the table. You can actually follow the same approach.
Facilitation
It’s highly recommended to have at least one experienced facilitator (at least in workgroup facilitation, better if also familiar with service design) per each 8/10 persons. We had only one at the Jam and it was pretty tough
Preparation Work
The preparation work can be shared through a Blogpost and a direct Email to registered attendees:
The objective of the info will be to:
Address potential ways for people to contribute
Linking attendees to materials and references:
Existing materials and definitions
Relevant UX design materials for people who don’t know
Great videos or articles
This should be published on the event blog at least a couple of weeks before and an extended version shall be sent via direct mailing one week before the event starts.
Lesson Learnt and Open Issues
People can’t stay focused for three days: we suggest to keep the event shorter. A good Idea could be meeting up on Saturday morning. Another possibility is to close the event on late saturday night
The subject should be broader/more loose: we had a bunch of good sessions but probably, a less focused epic would have helped to unleash more creativity and be more inclusive to non specialized attendees.
The power of open source hardware lies in the ability to build upon others’ work and good documentation is the key to making this happen. We believe that documentation best practices can increase contributions to open source hardware projects significantly. For this reason, OSHWA has partnered with Open Source Ecology and Everywhere Tech to host a collaborative event to arrive at an open source hardware documentation platform based on a set of shared standards. Read more about the event and register atopensourcewarehouse.org
Open product development has the potential to transform the economic system by making widespread collaboration possible. If there are easy mechanisms for viewing and updating open product documentation, products can evolve rapidly under the hands of many contributors. However, several obstacles often stand in the way of contributions and improvements. Below is a list of problems and possible ways to approach them.
There are no unifying standards or best practices for creating high quality documentation. Beyond the excellent work done by Phil Torrone, David Mellis and Nathan Seidle for open source electronics, there is no clear description of what should be included in OSHW documentation in order to facilitate the replication, modification and repair of all types of OSHW. The internet has many disconnected pieces of open source hardware documentation, but much of it suffers in quality or clarity. Clear guidelines for taxonomy and structure can help address this. We propose an initial set of standards and guidelines to be debated and refined.
Documentation for OSHW projects is dispersed across many platforms, websites, wikis and blogs. As the number of projects grows it’s becoming increasingly difficult to find them. We propose a taxonomy to identify both hardware and documentation modules, which may lead to an online OSHW repository.
No clear definition of scope exists. While open source electronics has become one of the most visible facets of open source hardware, there is much more. The scope of open source hardware, and its best practices, should include items such as medical devices, houses, cars, and washing machines.
Lack of standard formats, clear organization, and technical jargon makes it difficult for the layperson to understand existing documentation. The goal of an improved documentation platform is to enable anyone, at all levels of expertise, to study, reproduce and improve open source hardware.
Language is a barrier for the dissemination of open hardware plans. We propose that all textual descriptions be linked to Google Translate and that a Visual Language for OSHW be developed to describe fabrication procedures – see The Noun Project and IKEA’s assembly instructions as examples.
There’s no simple way to remix and mashup hardware. We propose a modular approach to open source hardware documentation that would facilitate remix, mashup and branching.
Derivative work is difficult to track. Taking into account that OSHW is developed mostly by iteration and derivation, the number of branches of any successful OSHW project is significantly higher than what is typical of OSS projects. Given the proliferation of derivatives and lack of clear information about each, it has become difficult for users and developers to identify and decide what branch of a project to replicate or derive from. We suggest that a dashboard be adopted by all open source hardware projects containing essential information about each version or derivative, such as: name, brief textual description, hi-res images, hardware and software version, attribution, open source label (indicates which parts of the hardware are open source), status brief (honest description of the state of the hardware, software and documentation), changelog, dependency (what other hardware is required to run/use the hardware), compatibility (what it’s compatible with), genealogy (information on the hardware’s origins, derivatives and replications), etc. In addition to this overview about the hardware itself, we also suggest that adoption of a build dashboard containing information on difficulty level, cost, as well as time, tools, space and skills required.
Lack of appropriate software for designing, displaying and sharing plans makes collaborative development difficult.
It’s difficult to update and evolve open source hardware designs due to documentation dependencies – one small alteration affects several other components of the documentation.
Documentation is time-consuming. A clean, easily accessible platform would facilitate this. If the barriers to contribution are low and a universally-understandable format is developed, then combined micro-contributions of numerous developers can make the arduous task of proper documentation tractable.
Unclear licensing and fear of infringement of intellectual property (IP) rights discourage people from producing documentation. Documenting involves reuse of content from other sources. If people do not understand IP licenses or have little understanding of their own IP rights to use content, they may be afraid to contribute documentation. A clear how-to on open hardware documentation IP Issues, as well as a legal support framework, can mitigate this.