This post originally appeared on opensource.com

The Open Source Hardware Association’s Hardware Registry lists hardware from 29 different countries on five continents, demonstrating the broad, international footprint of certified open source hardware.

In some ways, this international reach shouldn’t be a surprise. Like many other open source communities, the open source hardware community is built on top of the internet, not grounded in any specific geographical location. The focus on documentation, sharing, and openness makes it easy for people in different places with different backgrounds to connect and work together to develop new hardware. Even the community-developed open source hardware definition has been translated into 11 languages from the original English.

Even if you’re familiar with the international nature of open source hardware, it can still be refreshing to step back and remember what it means in practice. While it may not surprise you that there are many certifications from the United States, Germany, and India, some of the other countries boasting certifications might be a bit less expected. Let’s look at six such projects from five of those countries.

Bulgaria

Bulgaria may have the highest per-capita open source hardware certification rate of any country on earth. That distinction is mostly due to the work of two companies: ANAVI Technology and Olimex.

ANAVI focuses mostly on IoT projects built on top of the Raspberry Pi and ESP8266. The concept of “creator contribution” means that these projects can be certified open source even though they are built upon non-open bases. That is because all of ANAVI’s work to develop the hardware on top of these platforms (ANAVI’s “creator contribution”) has been open sourced in compliance with the certification requirements.

The ANAVI Light pHAT was the first piece of Bulgarian hardware to be certified by OSHWA. Olimex’s first OSHWA certification was for the ESP32-PRO, a highly connectable IoT board built around an ESP32 microcontroller.

China

While most people know China is a hotbed for hardware development, fewer realize that it is also the home to a thriving open source hardware culture. One of the reasons is the tireless advocacy of Naomi Wu (also known as SexyCyborg). It is fitting that the first piece of certified hardware from China is one she helped develop: the sino:bit. The sino:bit is designed to help introduce students to programming and includes China-specific features like a LED matrix big enough to represent Chinese characters.

Mexico

Mexico has also produced a range of certified open source hardware. A recent certification is the Meow Meow, a capacitive touch interface from Electronic Cats. Meow Meow makes it easy to use a wide range of objects—bananas are always a favorite—as controllers for your computer.

Saudi Arabia

Saudi Arabia jumped into open source hardware earlier this year with the M1 Rover. The robot is an unmanned vehicle that you can build (and build upon). It is compatible with a number of different packages designed for specific purposes, so you can customize it for a wide range of applications.

Sri Lanka

This project from Sri Lanka is part of a larger effort to improve traffic flow in urban areas. The team behind the Traffic Wave Disruptor read research about how many traffic jams are caused by drivers slamming on their brakes when they drive too close to the car in front of them, producing a ripple of rapid breaking on the road behind them. This stop/start effect can be avoided if cars maintain a consistent, optimal distance from one another. If you reduce the stop/start pattern, you also reduce the number of traffic jams.

But how can drivers know if they are keeping an optimal distance? The prototype Traffic Wave Disruptor aims to give drivers feedback when they fail to keep optimal spacing. Wider adoption could help increase traffic flow without building new highways nor reducing the number of cars using them.

You may have noticed that all the hardware featured here is based on electronics. In next month’s open source hardware column, we will take a look at open source hardware for the outdoors, away from batteries and plugs. Until then, certify your open source hardware project (especially if your country is not yet on the registry). It might be featured in a future column.

This post originally appeared on opensource.com

In this article, and hopefully more to come, I will share interesting examples of hardware that has been certified by the Open Source Hardware Association (OSHWA).

As an introduction to this series, I’ll start with a little background.

What is open source hardware?

Open source hardware is hardware that is, well, open source. The Open Source Hardware Association maintains a formal definition of open source hardware, but fundamentally, open source hardware is about two types of freedom. The first is freedom of information: Does a user have the information required to understand, replicate, and build upon the hardware? The second is freedom from legal barriers: Will legal barriers (such as intellectual property rights) prevent a user who is trying to understand, replicate, and build upon the hardware from doing so? True open source hardware is open to everyone to do with as they see fit.

What is the Open Source Hardware Association?

The Open Source Hardware Association is the umbrella organization for the open source hardware community. In addition to hosting the formal definition (mentioned above), OSHWA puts on the annual Open Hardware Summit and maintains the Open Source Hardware Certification Program.

What is the Open Source Hardware Certification Program?

“Open source hardware” can mean different things to different people. The Certification Program makes it easy to identify hardware that fully complies with the community definition of open source hardware. Certification is free, and hardware that has been certified is allowed to use the OSHW certification logo and a unique identifier assigned by OSHWA. The certification process makes it easy to be sure that you have provided all of the information needed for someone else to make use of your hardware and removed any legal barriers to use it.

Show me the hardware! A searchable list

Take a look at the entire list of certified projects. In this post, I’ll share two of my favorites.

A conference badge

The first is the badge for the 2018 Open Hardware Summit. The Summit always has great badges, and last year they were fully open sourced and certified (UID: US000133). The badges have an ESP32 micro-controller with built-in WiFi and E-Paper displays for the wearer’s name (or any other information, as the text can be customized and updated via a web app), and they are powered by two AA batteries.

The badge is a good example of how Open Source Hardware Certification handles third-party components. The ESP32 and the WiFi chip are not open source. However, that is not necessarily a barrier to certification. Certification requires the creator to open source what is known as the “creator’s contribution.” In other words, the creators need to open source all the elements they are responsible for and have the ability to openly license. Non-open components are allowed as long as they are documented and freely available without having to sign a non-disclosure agreement (NDA).

A business card holder

The second is a concrete business card holder. Besides its elegance, it is an important reminder that open source hardware is more than things that need batteries and soldering. The world of open source hardware is incredibly broad and should not be thought of only in the context of electronics (although there are plenty of open source electronics). The documentation for the holder includes tips on how to 3D-print the mold and how to pour and finish the concrete. Complete documentation is a great thing!

Hopefully, this has given you a small taste of things to come. In the coming months, the open source hardware roundup will highlight the broad range of certified open source hardware. Want to be included? If you want your hardware to be featured in an upcoming roundup, the first step is to get certified!

By “pretty easy” I mean “even I can do it” - an exceedingly low bar. It appears that the secret is kepler.gl, New York City open data, and a little bit of python. Click here to play around with my map yourself.

I have been wanting to try and do a neat map-based thing for a while but did not really have a good project to use as a hook. That changed when I found out that New York City makes film permit data available as part of its (excellent) open data portal. My neighborhood is always having streets closed off for shooting and I was curious how it compared to the rest of the city.

Preparing the Data

Getting the data is pretty easy - just download it from the film permit data site. While that data set is good, it isn’t quite ready to be used. The data set has a lot of information about location - borough, zip code, streets closed, etc. What it doesn’t have is specific latitude and longitude. Those numbers are going to be key to placing the dots on the map so I needed a way to get them. Since there are tens of thousands of entries, I needed a robot to figure things out.

Fortunately there are robots that are good at this kind of thing. Reverse geocoding APIs allow you to submit address information and in return they will send you lat/long. They can even work with not-quite-address data, like cross streets and zip codes.

In order to make things work, I wrote a python script to open the file from the City, send the useful bits to the geocoding API, and add the lat/long to a new file. I decided to use the Mapbox geocoding API because Mapbox is great.

It turned out that the data needed some cleaning before the API would give me what I needed. The first issue was that I had forgotten how to deal with the fact that the first row was a header row. Since I am lazy and there was only one input file I just deleted the row in the input file and manually pasted it back into the output file at the end.

in terms of more substantive issues, sometimes there were many locations associated with a single permit, so I decided to break the entries up by location. This code breaks up multiple-address entries into individual entries:

addresses = list(row[6].split(',  '))

The for loop then works through each address to make it its own entry in the output file:

for address in addresses:

If there were multiple addresses there were also multiple zipcodes. I admit that I cheated here. Instead of figuring out how to map the multiple zipcodes to the multiple addresses, I just picked the first zip code and used it for all of the addresses. My hope was that it would be close enough:

zip_split = list(row[13].split(', '))
first_zip = zip_split[0]

After playing with some test data I realized that at least 30% of the addresses I sent were not recognized by the geocoder. Helpfully the geocoder returned some address in West Africa when it was confused, so it was easy to find the errors. After playing around a bit I figured out that stripping the ‘and’ and ‘between’ from the addresses made the geocoder more accurate:

address_no_between = address.replace('between', ' ')
address_fully_stripped = address_no_between.replace('and', ' ')

I also realized that the order of terms mattered for the geocoder. Specifically, putting the street names at the end of the term seemed to help:

geocoder_entry = borough + ' New York City ' + first_zip + ' ' + address_fully_stripped
print("GC entry = " + geocoder_entry)


#looks up the address and pulls the lat and long
response = geocoder.forward(geocoder_entry)
counter += 1
collection = response.json()
lat = collection['features'][0]['center'][1]
#writes it to the csv
#row.append(lat)
long = collection['features'][0]['center'][0]

That greatly reduced the number of errors from the geocoder, although it did not eliminate them. In order to try and salvage something, if the geocoder returned a bad lat/long I resubmitted the query with just the first street name:

short_geocoder_entry = borough + ' New York City ' + first_zip + ' ' + short_address
print("Short GC entry = " + short_geocoder_entry)
response = geocoder.forward(short_geocoder_entry)
counter += 1
collection = response.json()
lat = collection['features'][0]['center'][1]
long = collection['features'][0]['center'][0]
row.append(lat)
row.append(long)
output_writer.writerow(row)

That got the accuracy rate high enough for me to stop worrying about it.

Using the Data

Once I had a correctly formatted data set it was time to move over to kepler.gl. At this point things became comically easy. The steps were just:

1. Go to kepler.gl
2. Upload the output file (make sure you have re-added the header row)
3. Add a filter tied to the field “StartDateTime”

That is the whole process. Kepler automatically recognized that I wanted to show the locations over time and added the timebar to the bottom of the screen (click here to play with the real one):

If I wanted to add hotspots over time (instead of individual dots) that was as simple as adding a new layer:

That’s basically it. I am excited to use this visualization for more things and I hope this post helps prove to you that pretty much anyone can make real looking map visualizations.

Earlier this week OSHWA announced that it would not be holding the 2019 Open Hardware Summit in Shenzhen, China. The stated reason for canceling the Summit is that China’s new foreign NGO law created logistical and bureaucratic barriers to holding the Summit in China. This reason is absolutely true – OSHWA was not going to be able to overcome the barriers created by the law.

However, there is also a second reason that I am wary of holding an event in China: China is currently holding one million ethnic Uyghurs in concentration camps, primarily because they are ethnically and religiously different from the Han Chinese majority. While OSHWA did not discuss the Uyghur situation in the Summit announcement, I believe that it is important to flesh out this concern for the community. I also believe that the open community should also consider this situation when it thinks about bringing major events to China.

The Situation

Uyghurs are a predominantly Muslim ethnic minority who primarily live in western China. China has currently placed perhaps one million Uyghurs in what are commonly described as detention camps, re-education camps, or gulags. Uyghurs are in these camps because of their racial and religious identity. For Uyghurs not placed in camps, the Chinese government has ordered another one million Chinese citizens, known as “big brothers and sisters,” to live in the homes of Uyghurs and report their activity back to the government. Uyghurs are also being forced to shave their beards, eat pork, drink alcohol, and generally partake in activities that violate their religious beliefs for the purpose of distancing them from those beliefs.

Speaking out about these camps - even for people outside of China - can be dangerous. China has routinely placed the relatives of Uyghurs outside of China in camps as punishment for speaking out. This makes drawing attention to and discussing this practice highly fraught in general, and and all but precludes responsible discussion of them within China.

Even if one were inclined to draw a moral equivalence between China’s treatment of Uyghurs and any number of activities undertaken by the U.S. government today, the combination of massive human rights abuses and punishment for activists who dare to raise concerns about the abuses has no equivalent in the United States or any other western country that I am aware of. That makes the situation worthy of discussion within the open community.

OSHWA and Uyghurs

The Uyghur situation presented a potential problem for holding the Summit in China this year: should OSHWA hold its major event in a country engaged in this kind of activity? While an easy question to ask, I will not pretend that this is necessarily a question with a straightforward answer.

OSHWA is an organization organized around a community of open source hardware. Human rights issues are not obviously part of that primary mission. At the same time, the open community strives to be inclusive. OSHWA is rightly proud of the Summit’s code of conduct and the Ada fellowship. While these things are not directly related to making open source hardware in a narrow sense, we recognize as a community that it is important to fostering an inclusive and vibrant open source hardware ecosystem.

In light of that, how should OSHWA evaluate human rights abuses in potential Summit host countries? Is it OSHWA’s place to speak out on human rights issues? If so, how should it do so and what kind of legitimacy does it speak with? To the extent that OSHWA has a community mandate to speak about open hardware issues, does that mandate extend to human rights issues?

Furthermore, OSHWA has many community members in China. What does it mean for their safety if OSHWA begins speaking out against human rights abuses there? If OSHWA comes out against what is going on with Uyghurs, should agreeing with OSHWA’s stance on that issue be a prerequisite for supporting open source hardware? What would that mean for OSHWA supporters in China who support the government’s activities? If OSHWA was to get involved with this situation, how would it handle other non-open hardware-related situations in the world? If OSHWA is worried about the situation, is it better to go to China and engage with people about it or simply walk away?

These are mostly answerable questions, but they are questions where reasonable people could disagree. In light of that complexity, OSHWA decided to take a path of constitutional avoidance with regard to the Summit. Because OSHWA could decide not to hold the Summit on relatively non-controversial procedural grounds – the foreign NGO law effectively made it impossible to hold the Summit in China this year – OSHWA decided not to wade into the Uyghur situation as well.

What are the Ramifications?

I think this was the responsible decision by OSHWA. That does not mean that the community - as opposed to OSHWA as an organization - should necessarily ignore the Uyghur situation. In fact, I believe that the open source hardware community has a responsibility to understand what is happening in a country that is so important to it.

I certainly would not have been comfortable participating in a Summit held in China with one million people in concentration camps. That discomfort would have been compounded by the fact that even pausing for a moment to recognize the existence of the camps at a China-based Summit would have exposed the organizers - Chinese and non-Chinese alike - to potential punishment from the Chinese government. That would make it irresponsible to do so.

I also am not suggesting that a relationship with China is binary. I continue to use products made in China and engage with Chinese companies. It should go without saying that raising this issue is not an attack on the Chinese people, and that I enjoy and hope to continue to grow my relationship with many members of the Chinese open source hardware community. In fact, I hope that there are open hardware events in China as part of Open Hardware Month in October.

Nonetheless, holding the Summit would have been a special type of engagement. OSHWA chooses the city for the Summit in order to highlight the importance of that city for the community. Special types of engagement should bring with them special types of responsibilities and reflections.

OSHWA does not have to directly grapple with how the Uyghur situation interacts with the Summit this year. However, there are many other organizations in the open source hardware community (and the larger maker community) that are considering holding events in China this year. Assuming they can find a way to navigate the NGO law (or that the NGO law does not apply to them), I hope that they will at least pause to consider what their event might mean in a country with a million people in concentration camps.

This post originally appeared on the OSHWA blog.

This blog post is an update for the OSHWA community about the 2019 Open Hardware Summit in Shenzhen, October as Open Hardware Month, and how OSHWA will think about Summits going forward.

The tl;dr version of this post is:

1. OSHWA will not be holding the Open Hardware Summit in 2019
2. OSHWA will be encouraging locally-organized events and gatherings across the globe as part of Open Hardware Month this October (email us at info@oshwa.org if would like to host one!)
3. OSHWA will shift the Summit to the spring starting in 2020. The Summit will also be held in the same city for at least 3 years starting in 2020.

There is a lot to unpack here, so let’s get to it.

2019 Open Hardware Summit in Shenzhen

At the end of the 2018 Summit OSHWA announced that it would be holding the 2019 Open Hardware Summit in Shenzhen, China. Shenzhen has a vibrant local community of open source hardware enthusiasts. Many members of the OSHW community were also very excited for the opportunity to travel to a location that is so central to manufacturing innovation.

Unfortunately, in 2017 China implemented a law governing the activities of non-Chinese NGOs operating in China. This law created a number of bureaucratic hurdles for organizations like OSHWA that were interested in holding events in China.

Among other things, the law requires OSHWA to find a local Chinese Partner Unit (CPU) willing to act as our sponsor for the Summit. CPUs can only be certain types of organizations, such as universities or registered Chinese NGOs. Companies cannot serve as CPUs. The CPU must also be willing to undertake a significant number of bureaucratic steps to officially register the event and coordinate with local authorities. In addition to the process required of the CPU, OSHWA itself would have to undertake a significant and burdensome number of steps to collect, verify, and provide paperwork to Chinese authorities (see this article “Reams of Paperwork: Preparing Documents to Get Official Status in China” for a sense of what is involved).

OSHWA has spent the last few months trying to identify a suitable CPU. We have been unsuccessful, and do not have confidence that we will be successful in the future. Furthermore, even if we were able to find a suitable CPU, OSHWA cannot justify the time and resources required to comply with the various filing requirements associated with the law.

As a result, OSHWA decided that it was better to cancel the 2019 Summit now, before speakers and attendees had made commitments and travel arrangements.

That being said, OSHWA is still committed to supporting the OSHW community. That is why we are pairing this announcement with two additional announcements.

October as Open Hardware Month

OSHWA has traditionally supported October as Open Hardware Month. Open Hardware Month is an opportunity for the community to hold local events, hackathons, and documentation days as part of an international movement.

OSHWA wants to take this opportunity to expand Open Hardware Month events. We will work to provide resources for the community to create to local events, aggregate information to make it easy to find events in your area (or know that you need to organize one), and collect stories, video, and images of the events as they occur. These events will not be OSHWA run or carry the formal OSHWA name. We believe that Open Hardware Month will provide us an opportunity to shine a light on open source hardware events happening around the world. It will also provide an opportunity for local communities to raise their hand and be recognized by the global OSHWA community. Please email info@oshwa.org to learn more and volunteer to be involved.

Spring Summit 2020

Cancelling the Shenzhen Summit and focusing on Open Hardware Month will also allow us to shift the Summit to the spring. Over the years a number of Summit participants have told us that the spring is generally less crowded with events and obligations, so this shift should make it easier for more community members to attend.

Starting with the 2020 Summit OSHWA also intends to commit to a single US host city for at least three years.

For the past year the OSHWA board has been debating two alternative paths for the Summit. The first path would continue the pattern of moving the Summit every year. The benefits of this path is that it allows the Summit to come to the many different communities that support OSHW. The costs of this path are that it makes the Summit more expensive to operate because OSHWA needs to spend time and resources learning a new city every year. Switching cities also makes it hard to capitalize on the enthusiasm of local attendees in order to convert them into full community members.

Conversely, the alternative path is to commit to a single city for multiple years of the Summit. The benefits of this path is that it allows OSHWA to run the Summit significantly more efficiently and makes it easier for community members to plan. Holding the Summit in a single city allows OSHWA to grow the number of attendees by turning opportunistic local attendees into more permanent members of the community. The cost of this path is that it prevents us from moving the Summit to all of the communities that support OSHW.

After significant discussion, OSHWA has decided to adopt the single city approach. This decision was easier because we paired it with the expanded Open Hardware Month. We believe that Open Hardware Month will help fill at least part of the gap created by a stationary Summit.

While none of these decisions are being made lightly, OSHWA believes that combined they allow us to create a rhythm that is more supportive of the vibrant OSHW community. Open Hardware Month in the fall will shine a spotlight on all of the local OSHW communities around the world. The Summit in the spring will provide those communities a single place to come together and meet in person.

As always, OSHWA exists because of its community and we want to hear from you. Please let us know what you think in the comments below or in the forums.