Another week has absolutely screamed by, and the first five panels of BeanCounters are entering assembly at PCBWay as you read this. These panels will be used to assess the build quality and make any necessary adjustments for the campaign fulfillment run. Having worked with PCBWay in the past—and given the simplicity of the design—I don’t expect there to be any electrical issues with the build. My main concern is about the mechanical fit of the PCB to the resin chassis. As single boards they’ve always fit perfectly, but single boards are difficult to handle in a production environment. This requires the design to be panelized, which means that at least two edges of the board need to be connected with a frame. The final dimensions of the board, after it’s separated from the panel, will be affected by this process, so there may be some trial and error involved in achieving the same seamless fit. In the meantime, I’m keeping busy making tweaks to the firmware and trying to stay ahead of any supply-chain surprises that might be lurking ahead of us.

I could go on and on about manufacturing and logistics, but today I want to talk about business philosophy instead. On May 6th of this year, BeanCounter was registered as OSHW Certified (US002097) according to Open Source Hardware Association standards. The OSHW mark certifies that BeanCounter meets the community requirements for licensing and documentation of open source hardware projects. Open source hardware is something that I’m passionate about, so it’s important to me that BeanCounter is not just open in name, but practically accessible and useful to the community.

Why Open Source?

I probably don’t need to spill too much ink here about the importance of open source hardware. If you’ve stumbled across the BeanCounter campaign then chances are you’re already operating in the open source community. It stands to reason that open source development is good for innovation: By making their work publicly available, designers avoid re-inventing the wheel. Properly documented and modularized, open source projects are built out of bricks that get better every time someone uses them. This represents the best intentions of the US Patent system, encouraging creators to share their innovations instead of keeping them as trade secrets. However, under the patent model, creators are incentivized with the right to exclude others from using, making, or selling their invention. In practice, this right can only be exercised by people with the time and money to seek out infringing parties and effectively navigate the legal system. Using the legal system in this way also invites frivolous infringement claims by so-called patent trolls and creates a predatory industry of Invention Promotion Scams.

In contrast to the patent model, open source development has a low barrier to entry and focuses on providing benefits to downstream integrators and developers of the technology, rather than the originating developer (or developers) in particular. Breaching an open source license generally entails an attempt to claim open source technology as proprietary. Because of this, legal action is only ever used to keep things open rather than keep them private. There are always more parties who will benefit from a technology being open, which means there’s no incentive for legal trolls and a shared incentive within the open source community to legally defend open source licenses. In short, open source allows more technology to be developed more quickly by and for more people.

Why the OSHWA in Particular?

There are a lot of ways to participate in open source flavored development, some of them are more useful than others. Open source hardware is different from open source software in that it contains elements that extend beyond the realm of things like Standard Copyright, Creative Commons, GNU Licensing, and Public Domain. Defining the rights surrounding a piece of hardware can require a combination of licenses and documentation that make it potentially perilous to incorporate pre-existing work into your own. Not all licenses are created equal. In my day job, we released a lot of early work under a Beerware License, which we thought was fun and clever and even resulted in us receiving a fair number of beers! I’ve personally released work into Public Domain or under a so-called Apathyware License. However, it turns out that these novelty licenses actually discourage people from using the work because, while they don’t restrict use in any way, they also don’t explicitly allow it. This can make it difficult for downstream and end-users to know their rights.

In the past 30-or-so years, several organizations have attempted to define a "community definition" of open source hardware and to set a standard for licensing and documentation. As with any such endeavor, there have been fights and schisms and competing philosophies. However it would seem that the Open Source Hardware Association has the most buy-in at the moment, and they’ve done a great job of developing and maintaining a community definition. They also own a compliance mark that can be used to identify compliant projects. Not only that, they provide and maintain a database of these OSHWA-compliant projects, which makes them easy to discover and identify while providing a central repository for their associated licenses, trademarks, and documentation. In short, it seems that an organization like OSHWA needs to exist, and right now they’re the most effective example.

Competitive vs Cooperative Innovation

(It’s probably worth noting that the views I express here are not necessarily those of the OSHWA)

Because open source development is basically economically agnostic, a lot of business owners and investors have rushed to make the case that using and developing open source hardware is competitively advantageous. I tend to agree, actually, but I also believe that we’d be obliged to do it even if it were a disadvantage in the current economy. It’s a matter of dogma, at least in the USA, that the explosion of technological innovation that started in the industrial revolution and continued into the information age was the direct result of capitalist free-market competition. Independent, rational actors competing for market share invented new technology to gain competitive advantage over their peers. Of course the reality of the situation is much messier and tends to paint the "free market" in a different light. No invention is born, fully formed, out of whole cloth. Many of the things that we consider great "inventions" of the late-19th and early-20th centuries actually represent a form of intellectual enclosure wherein incremental improvements and commercial embodiments of publicly funded or Public Domain knowledge were treated as Promethean leaps in human achievement—a notion that made a handful of people very rich. Beneath every engineering marvel is a mountain of scientific research born of passion and cooperation. How many very wealthy scientists do you know? I’m willing to bet it’s not very many.

So, yes, participating in open source development may very well give your company a competitive advantage over closed source companies. But in my mind, that’s icing. The real reward is that is lends no intrinsic advantage over other open source developers. It also contains no mechanism for creating an artificial advantage through legal action or denial of resources. Open source companies are left, then, to cooperate. So how does a company perpetuate itself in a cooperative economy? If you’re sharing all of your intellectual property (trademarks aside), what value do you offer to your customers? Well…

You Make Things

Often times, we get so caught up in discussions about designs and IP and technologies that we lose sight of the fact that there is a product at the end of this whole thing. There’s an object that someone wants to have. If you want to create value for people, make a thing. Your competitors will steal your ideas (your cooperators will share your ideas) but they can’t sell your warehouse full of things. When my father was still in college, working toward his Mechanical Engineering degree, a professor once told his class (paraphrasing) "If you ever invent something, don’t patent it. Just find a way to make it and sell as many as you can before someone rips you off." and while this advice strikes me as ruthlessly pragmatic, I think it’s essentially good advice. For your own good, just make it. For everyone else’s good, tell them how. Someone’s gonna figure it out anyway.

To that end, I have finally published a guide in the BeanCounter Wiki outlining how to build a BeanCounter from its source documents. Frankly, unless you happen to have a lot of the parts on hand and don’t value your time that much, it’s not a way to save money over buying one. That said, I received several requests from people who wanted to support the campaign but were unlikely to be able to import their BeanCounter due to geopolitical circumstances. This guide is largely for them.

And for everyone reading this, I’m massively grateful that you want a BeanCounter and that you’re willing to help me make something.

Cheers,
-Nick