Commercialization-as-a-Service - A Missing Layer of Open Hardware?

Today the Engelberg Center released a report from the Open Hardware Distribution & Documentation Working Group that explores what is really needed to create a distributed manufacturing network for open hardware. You can find the official launch post here and the report itself here. I recommend checking it out.

This post focuses on one part of the report: the idea of “Commercialization-as-a-Service.” For me, this was the most intriguing thing to come out of the year’s worth of discussion within the Working Group (and it was a discussion full of intriguing things!).

Open source hardware is constantly working by analogy to open source software, so let’s start there. With open source software, the manufacturing and distribution layer is fairly straightforward and so lightweight that it is easy to miss. Publishing code online effectively manufactures and distributes it worldwide.

Admittedly, in reality the “it just happens” nature of open source software distribution breaks down pretty quickly. Nonetheless, “pretty quickly” is not immediately. The ease of code distribution online means that a piece of open source software can get at least moderate use and build a decent sized community without being supported by significant commitments to building out infrastructure.

That is not really the case with open source hardware. While it is true that you can easily post design files for hardware online, design files for hardware are not hardware. In order to get beyond a relatively small core of people who will assemble and build their own version of the hardware based on instructions, developers of open source hardware are likely to confront a need to begin packaging physical objects and distributing them to others. These objects might take the form of a kit that others assemble, fully constructed hardware, or something else entirely.

Regardless of what form it takes, this manufacturing and distribution layer becomes an independent obligation for the team much earlier in the hardware lifecycle than it would in the software lifecycle. Furthermore, this layer is probably further from the work of designing the hardware than the equivalent responsibility is from writing software. That means that there is no guarantee that the team that originally came together to design and build the hardware has someone (or a group of someones) who are also excited about spinning up a manufacturing and distribution network. That is especially likely to be true in the context of research lab-developed hardware (which is the focus of the paper).

Where does that leave things? Manufacturing and distribution of open hardware becomes an important stand-alone task early in its development cycle. At the same time, the team working to create that hardware may not be excited about engaging in that task.

Enter Commercialization-as-a-Service

One way to try and solve this problem is to get more people excited about building out manufacturing and distribution networks. An alternative approach would be to make open hardware projects less reliant on building their own manufacturing and distribution networks in order to succeed.

This second option may be most realistic in situations where open hardware has been developed in scientific research lab contexts supported by grant funding. In those situations, a grantor has already paid for the development of the open source hardware in the context of the specific project. Currently, in most situations that hardware either remains within the developing lab or is effectively abandoned.

Creating commercialization-as-a-service could make it much more likely that open hardware developed in one lab becomes available to the research community more broadly. That service layer could develop a standing network of international manufacturing and distribution partners, as well as expertise in productization and marketing of hardware. It would work as a pump, pulling proven hardware out of labs and pushing it to other researchers worldwide. In doing so, it would reduce the current ‘unicorn’ condition of academic open hardware success, whereby a successful open source hardware project needs a team that happens to combine the engineering skills to develop the hardware and the logistics skills to manufacture and distribute it.

Building this layer feels like the accelerant role that foundation and other grantors are well positioned to play. Assembling the expertise required to productize, manufacture, and distribute hardware can be done once and applied to a range of hardware. Doing so could greatly increase the impact and adoption of the hardware that funders are already funding. Conversely, without building this layer, these funders are making it much more likely that effective hardware remains tucked into individual labs, hidden from the rest of the research community.

Of course, this is just one of the things that’s in the new report. You can read the entire thing here.

Header image: New Inventions of Modern Times, The Invention of the Clockwork, plate 5, from the Met’s Open Access collection.

Keep 3D Printers Unlocked (the win!)

Today is is even more clear that copyright law does not prevent you from using whatever material you want in your 3D printer.1

That is because today the Register of Copyrights submitted her recommendations on the petitions to exempt various activities from 17 U.S.C. § 1201(a)(1)(A). In practice, this document gives people permission break digital locks for specific purposes.2 Whatever you call it, the recommendations include granting the request to expand the scope of the current rule that allows you to unlock your 3D printer and use the material of your choice.

As I explained in a previous post, every three years the Copyright Office gets to give people permission to break digital locks for specific purposes. In the past, the Copyright Office had included permission to break any digital lock that prevented someone from using the material of their choice in a 3D printer.

This was good, but the language could have been tightened up a bit. So, this year, I submitted a request to slightly modify the language of the rule in two ways.

First, I asked the Copyright Office to change the word they used to describe ‘what you put in your 3D printer’ from ‘feedstock’ to ‘material’. ‘Feedstock’ was a word left over from previous rulemakings and ‘material’ is much more widely adopted. To be clear, it is 100% my fault that the Copyright Office started using ‘feedstock’ so I am glad to be able to end that practice with this year’s rule.

Second, I asked the Copyright Office to remove language that only gave permission to break digital locks that were ‘microchip-reliant’. This seemed like an unnecessary restriction on the rule. If a digital lock was preventing the use of a third party material, there was not a good reason to litigate whether or not that lock was ‘microchip-reliant’.

The Copyright Office did both of those things. The new class is described as:

Computer programs that operate 3D printers that employ technological measures to limit the use of material, when circumvention is accomplished solely for the purpose of using alternative material and not for the purpose of accessing design software, design files, or proprietary data.

Both the petition to renew the original exemption and the petition to make these changes went unopposed (thank you to both the Free Software Foundation and NTIA for supporting the changes). Hopefully that means that the rule will be fairly stable going forward, and that renewing it again in three years will be a straightforward affair. Stay tuned for that, I guess?

  1. Why would copyright law prevent you from using the material of choice in your 3D printer anyway? It shouldn’t even be a thing that we are worrying about. However, Lexmark tried this foolishness with 2D printers back in the day and lost. Part of the purpose of requesting this exemption is to try and avoid having to litigate that point again for 3D printers. 

  2. Technically, what is happening here is that the Register of Copyrights is making a recommendation to the Librarian of Congress as to what activities should be exempted from the prohibitions on circumvention contained in 17 U.S.C. § 1201(a)(1)(A). In practice the Librarian almost always follows these recommendations. 

Next Wave Openness

Openness is on the march!

Actually, openness has been on the march for some time. As it marches, the fundamental nature of the most important debates around openness appear to be changing.

A number of different open communities - open software and hardware, open culture, open data, open GLAMs, etc. - seem to be entering a new phase of their development. This new phase is characterized by their successful growth into and adoption by the mainstream.

This new phase comes with new debates. In the early days of openness advocacy, the core debate involved a small group of people working to defend the very concept of openness to a skeptical world. This debate played out between openness advocates within the community and openness skeptics outside of the community. It was about the fundamental legitimacy of the concept of openness. The dynamics of this formative is-open-even-a-real-thing-? debate shaped the community in critical ways.

While debates about the fundamental legitimacy of openness continue (and will continue), the growth and success of openness has given open communities confidence that the core concept of ‘open’ is viable. This has helped shift the discussion around openness in new directions towards new questions. The key debates in openness advocacy now involve a larger group of people trying to reconcile openness with other values that they hold to be equally dear.

Today’s debates are shaped by two related factors: first, that openness is no longer fighting to prove its fundamental legitimacy; and second, that the openness community is now big enough to include people who view openness as one of many important values. The openness community is now larger than its original ‘single issue voters’.

This larger openness community is struggling to balance its interest in openness with other closely held values. Unlike in the past, where other values were seen as competing with openness, today’s debate strives to find ways for openness to coexist with these values. However, the fact that both sides of these discussions believe in openness can be a challenge to the adversarial debate styles that openness communities developed in earlier eras.

This confidence about the sustainability of openness and concern about other priorities results in debates that would have been hard to anticipate and appreciate in the early days of openness advocacy - concerns about openness and privacy, openness and control, openness and ethical uses. These debates shift the focus from an external conversation - between the community and skeptics - to an internal conversation - within the community itself. While none of these debates are unprecedented in these communities, their centrality does feel like a shift.

That creates a challenge for the openness community broadly, and for specific openness communities. If they continue to operate under the old debate models, the communities will treat these internal criticisms as external threats to the foundation of openness. In doing so they risk alienating the expanding community at what could be a moment of triumph. Alternatively, these communities can reorient themselves to engage with the new criticisms as a way to strengthen the work, make it more inclusive, and ultimately broaden the adoption of openness. This is a harder path, one that may prove to be self-destructive. However, it may also be the only way to continue to expand openness.

Openness Communities Start by Overcoming Skepticism

In most cases, openness communities were founded in environments that were skeptical towards openness.

Openly sharing software or hardware, making books or photographs parts of the commons, releasing data to the public, and inviting anyone to make use of GLAM collections were fringe ideas that needed to prove their legitimacy to the wider world. Early advocacy communities tended to be relatively small and homogeneous. While these communities were often full of internal debate, their most important arguments were with the rest of the world.

The rest of the world was largely skeptical of arguments for openness and questioned or rejected the conceptual frameworks that the open advocacy communities represented. As a result, openness communities often adopted a “for us or against us” posture towards debates around the merits of openness. They established bright line rules to help define ‘true openness’ to reduce the risk of bad actors gaming the system. Questioning these tenets was viewed as akin to questioning the legitimacy of openness itself.

This posture helped to fuel the growth of openness. However, it also created patterns for responding to critiques that can cause problems in a more expansive openness community.

Openness Has Won

While there is still a long way to go, in many cases openness has spread more effectively than most of its original proponents could have hoped. Even opponents of openness have retreated from categorical “openness can never work” arguments towards more nuanced “openness does not work in this case” arguments. The world is still full of open skeptics, but it is also full of success stories that prove that open approaches can work in a broad range of situations.

One result of this success is that the open community is much larger and more diverse than when many of the original open communities began. These diverse members bring a broader set of expectations and concerns to internal discussions within openness communities themselves.

This diversity of expectations united under the banner of openness means that the openness community as a whole, and individual open communities in particular, are grappling with a new round of conceptual concerns from within. Unlike the traditional external critics of openness, these concerns do not question the fundamental legitimacy of openness. Instead, they start with an assumption that openness is good, socially productive, and something that should be supported. They then attempt to incorporate other values that community members view as equally important to openness in the hopes that these values do not contain fundamental conflicts.

Community members with these concerns are not trying to eliminate openness from the outside. Instead, they are working to improve openness from within by finding ways to accommodate their additional concerns and uphold what they view to be important values.

What Does This Look Like in Practice?

It is all well and good to make grand pronouncements about cultural shifts. How does this conflict manifest itself in specific openness communities?

Ethical Open Source Software Licensing

One of the core tenants of the open source definition is “No Discrimination Against Fields of Endeavor.” In practice, this prohibition means that it violates the open source definition to prevent open source software from being used in ways that creators find unethical.

There are good reasons to adopt this kind of rule. Ethics are slippery. They can evolve over time and be different in different contexts. They can also be incredibly hard to define in a consistent way. Introducing ethical constraints to a copyright license can add instability to the entire process.

And yet… a growing community within open source believes that instability is a price worth paying. The more central software becomes to our lives, the more important ethical considerations may be to how it is used. People who understand themselves to hold openness as a core value are working to combine it with other values they hold equally dear.

For the purposes of this post, the most important feature of the ethical open source debate is that it is coming from within the open source community. Advocates for ethical open source fundamentally believe in open source as a development model. They are not questioning its core concepts. Instead, because they believe in open source so strongly, they think it is important that it harmonize with other equally important values.

Creative Commons has been incredibly successful in building a commons-based approach to licensing. This success is built upon the Creative Commons licenses themselves, and also upon the social and cultural structures that have grown around the licenses. In many ways, the Creative Commons licenses - and the icons that the organization maintains to represent them - send a signal in support of openness that is just as much cultural as it is legal.

While an undeniable marker of Creative Commons’ success, these cultural signals can raise questions when they are detached from legal reality. For example, many members of the 3D printing and open source hardware communities attach Creative Commons licenses to objects that do not have copyrights that can be licensed. At best, this converts something that was designed to be a legally binding document - a license - into something more like a cultural signal or a not-legally-enforceable request.

This shift raises the potential for all sorts of problems or misunderstandings between creators and users. Is it a sign of a corruption of Creative Commons? Or an exciting expansion? While reasonable minds can disagree, both sides of the disagreement start from an assumption that Creative Commons - and the openness it represents - is a good and viable thing.

As with open source software, members of the Creative Commons community attempting to use the licenses outside of the scope of copyright are starting from a place of enthusiasm about what Creative Commons represents. That enthusiasm motivates them to try and bring what they understand as the core of the Creative Commons ethos to places that were never intended by the original creators of Creative Commons. They are doing it “wrong” not out of spite for the work of Creative Commons, but rather because of their affection for Creative Commons.

Who Should Control Open GLAM Collections?

The Open GLAM (Galleries, Libraries, Archives, and Museums) movement is an effort to encourage GLAM institutions to make their collections more accessible to the public. While this can take many forms, one of the most common ways to implement an Open GLAM agenda is for an institution to digitize the works in its collections and make those digital versions available online in an open and unrestricted way.

A core goal of the Open GLAM movement is to make more culture available to more people with fewer restrictions on what those people do with the collections. Institutions large and small have joined the Open GLAM community by opening parts of their collections.

While this goal of making more culture available to more people with fewer restrictions drives the push for Open GLAM, it can also overlook the sources of those collections and sidestep questions of who should have the authority to make culture more available.

Projects such as the TK (Traditional Knowledge) Labels are designed to give Indigenous communities a voice in how GLAM collections that include objects from their cultures are used by the wider world. Scholars have also raised questions in other contexts about who should be empowered to decide when an artifact is made available to the broader public.

Viewed one way, these efforts act against the core goals of openness by limiting how ‘open’ objects can be used. Viewed another, these are attempts to find a version of openness that includes equally important values like representation and inclusivity.

However one is inclined to view them, these types of critiques are not rooted in a rejection of the core concepts of Open GLAM. Instead, they are being raised by people within the Open GLAM community who believe that there are better ways for Open GLAM to achieve its goals. They believe that Open GLAM will be strengthened - not undermined - by incorporating concerns and stakeholders that were largely left out of the original discussions. To the extent that these new tools introduce restrictions on the use of open access works, those restrictions assume full open access is a natural starting point for the discussion.

Does This Need to be Resolved?

Ethical open source licensing, Creative Commons without copyright, and a slightly less open Open GLAM are examples of this tension, but they are not alone. You can find similar dynamics in discussions around privacy concerns in connection with open data, business models in connection with open publishing, and even questions about how to deal with dominant platforms in connection with the open internet.

In each of these communities it is easy - and tempting - to try and push these questions aside, categorizing them as beyond the community scope or undermining the push for openness. After all, the universal principles that founded these communities have gotten us this far. They are a success!

This type of doctrinaire approach tends to work well until it doesn’t. If open continues to succeed and grow, open communities need mechanisms to incorporate the broader set of people who will make them up. It is not reasonable to assume that this new universe of open enthusiasts will come with exactly the same values as the founding cohort, or to declare that the concerns that they bring to the community should be dismissed out of hand.

Instead, open communities should begin prioritizing developing tools and processes to manage internal dissent about the limits of openness in ways that feel legitimate to everyone involved. This does not mean that open communities need to accept all of the concerns or accommodate them. It does, however, mean that they need better ways to give them a fair hearing.

Header image: The leaders of two armies conversing, their respective troops and camps on either side; above, Minerva observes from her chariot; set design from ‘Il Pomo D’Oro’ from the Met Open Access collection

Behold CleverHans.org

On November 13, 2014 I purchased the domain cleverhans.org because I decided that the world needed a digital version of Clever Hans.

At the time, I did not know how to program in any meaningful sense. I had used logo in elementary school and taken a class in BASIC in middle school. I also used markdown to write posts for the Public Knowledge blog. Nonetheless, the world needed digital Clever Hans and CleverHans.org was going to be my excuse to learn how to do it.

Almost seven years later, today I finally figured out how to put a functional CleverHans.org site on the internet. It took longer than I thought.

Along the way, I took massive detours. I learned some python (the hard way, of course). I learned some arduino, processing, p5.js, circuitpython, and even ml5.js. I bought books and jumped around the internet. Using Coding Train to learn p5.js tricked me into learning some javascript. I converted this site into Jekyll. I played around with phaser. I built other dumb things.

I learned the basics of most of these without mastering any. Every time I thought I had things figured out, I would come back to Clever Hans. And every time I came back, I discovered a new thing that I did not quite know how to do.

Finally, I started another run at it over the summer. I purchased Emanuele Feronato’s phaser book and this time it actually worked. Everything I had learned from all of my stabs at programming finally came together. As a bonus, in the years since I purchased the domain, tools like github and cloudflare pages meant that I could host the site for free.

CleverHans.org is a dumb site that does not do very much. It certainly does not look like something that took seven years to build. Fortunately for me, it is just dumb enough and does just little enough that I always felt like a working version was just around the corner. In its way, it provided just enough motivation to get me to learn a bit more programming and stick with it just a few minutes longer.

And now the world does have a digital version of Clever Hans. On the internet. What a world.

Licenses Alone Do Not Govern Behavior in Open Source

A recent kerfuffle around an open source software creator asking for their package not to be included in a larger project has turned into a kind of rabbit-duck illusion for the open source community. What does it mean when the creator of a software package uses their social power - but not their legal power - to try and influence user behavior? Are they violating the spirit of open source? Or simply making requests that acknowledge open source realities?

What Happened

The actual back-and-forth is in the pull request discussion. The citadel of internet debate that is Hacker News will give you a sense of the larger community response. Briefly, what happened was:

  • The creator of an open source software package asked that the package not be incorporated into a larger project. The creator acknowledged that it was technically legal to incorporate the package, but asked that it not be included anyway.

    As the author of the package that is being re-packaged here. I’m against it being repacked into here. While licensing wise I cannot stop you, I do hope you can honor my request. Thank you for considering respecting the author’s wishes.

  • When pushed by the project’s maintainers, the package creator explained that they were worried that including the package in the larger project would result in many support requests from the community.

    If users experiencing issues with [the package], they will knock on my door. And I’m not willing to support that or accept that burden.

  • Downstream maintainers pushed for more information or explanation. The creator continued to express disinterest in having the package included and in a conversation about the decision
  • Eventually the creator threatened to relicense the package in a way that would make it legally incompatible with the project

Online opinion is split on this situation. However, some substantial part of the community has responded with a version of:

Seems like an author that doesn’t understand the spirit of FOSS.

What can be learned from this? Is this kind of request really against the spirit of FOSS?

Distinctions Between What the Law Allows and What Social Norms Allow are Real and Relevant (I)

It is notable that the creator did not kick off this discussion with the threat of legal action. Instead, the creator simply requested that the package not be included. They then explicitly acknowledged that they did not have the legal power to prevent it.

This was a request that no one had a legal obligation to respect. And yet, the creator made it because (presumably) they believed that the package maintainers lived in a world that was governed by more than black letter legal rules.

This strikes me as a totally healthy response on behalf of the creator. They clearly understood the consequences of releasing software under an open source license and the potential consequences of being included in a popular software package. The creator expressed these concerns by way of a social request instead of a legal threat because part of living in society is being able to resolve disputes without going to court.

We will never know, but it strikes me as entirely plausible that the creator may have been willing to leave it at that - as a request that may or may not be complied with - until the maintainers decided to follow up.

To be clear, the maintainers’ initial response also strikes me as a reasonable one. They probably wanted to understand the concerns that would motivate someone to make the request. They may have also hoped to be able to address those concerns and/or talk the creator out of the objection.

Unfortunately, this very human response by the maintainers also happened to push the creator to do exactly what the creator was hoping to avoid by raising the concern - spend time talking to people that they do not know about their package. Eventually, after the discussion continued, the creator decided to threaten to relicense the package in a way that would legally prevent inclusion.

It is important to recognize that this discussion ran on parallel tracks. One track was based on legal requests (or the lack of legal requests). The other was based on social/cultural requests.

That social/cultural track has the potential to be just as powerful as the legal one (in fact, it is the basis for this idea). Its existence illustrates that the reasonable resolution of the dispute did not have to rely on a strict interpretation of legal rights. Society is more than the law! The maintainers could have ignored the request and faced meaningful social/cultural consequences without any sort of legal enforcement. Social norms are real and create real change in the world. Even in open source.

Distinctions Between What the Law Allows and What Social Norms Allow are Real and Relevant (II)

On the flip side, the package in question is licensed under an MIT license. That license includes a pretty clear “anything that breaks is not my problem” disclaimer (in all caps):

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

If the legal rules were all that mattered here, the text of the license makes this entire dispute a non-issue. The creator offers the software as-is and disclaims any responsibility for it. Why would anyone come back to them if the software had a bug?

Of course, the text of the license does not match social expectations. Licensing terms aside, the creator recognizes that there is a social expectation in the open source software community that creators maintain packages - or, at a minimum, that it is acceptable for users to reach out to creators to ask for support and/or flag bugs.

While the creator seems to have understood that they have no legal obligation to deal with these requests, they also understood that they might have a social/cultural obligation to deal with them. Or, at a minimum, that the tools available to open source software creators make it hard to ignore a flood of requests. No amount of pedantic textual analysis of the license terms changes that.

Another Example of the Dark Side of the Power of Open Source?

This fits in with a long list of stories about how small pieces of code are used by millions without any sort of support for maintainers of the code. In some ways, this is a success story - a random person can create something that is used by millions! In other ways, it is a tragedy - a random person can create something that will make millions of people angry if it breaks!

Regardless of how you see this dynamic, it is pretty clear that it can create disincentives for individuals (and small groups) to strive for success in open source software. While companies like Tidelift are working to help solve this problem, being aware of the problem - and wary of how the problem might impact you - is far from failing to understand the spirit of open source software. In fact, it may be an incredibly clear-eyed understanding of how the spirit of open source software interacts with the reality of open source software. Furthermore, framing concerns about that dynamic as a social objection instead of a legal objection seems deeply within the spirit of open source software.

As a related community, this type of creator burden is something that the open source hardware community should be aware of and work to address. At the same time, I am not convinced that it is exactly the same type of problem in hardware as it is in software. To the extent that open source hardware includes open source software the problems are essentially identical. However, it is different when applied to the hardware itself.

That difference rests in the fact that design and distribution of software is collapsed into a single step - just post it to the repo. In hardware those steps are quite distinct. Designing open source hardware is quite separate from distributing actual pieces of hardware. That may make it harder for a single person to be responsible for maintaining a piece that is incorporated into millions of projects without any sort of support. But that’s another blog post for another day. Even if the dynamic is not identical, it is certainly similar enough to think about and try to avoid in open hardware.