Community Economics Redux

Let’s add another element to the OSH community—economics. Community economics are the workings of our functional interactions: how we each play our roles within the community so everyone gets what they’re looking for—and everyone is better off for it.

In a project-oriented OSH community, engineers and developers can make things even faster and better than previously imagined...for much less than companies with huge R&D facilities. What’s interesting is that the OSH community would be far more in tune with customer demand for designs and features than most companies would be. Typically, a tech company will conduct market research to get a sense of what customers want.

In this situation, the OSH community not only has the ability to contribute to projects, but also the chance to select and modify the projects they would most like to see. And whatever comes out of this development will not only be high quality and less expensive, but given the grassroots approach, it will also satisfy customer demands more than ever before.

The difference between open source hardware and software is that software requires little or no supplies and financial investment—where hardware does. As Matt discussed in an earlier post, the success or failure of OSH depends on what a single individual can achieve within a reasonable personal budget. Based on this, I see two approaches to making OSH successful (i.e., maximizing what each individual can achieve on that budget)

1) Incentivize involvement to offset personal financial investment
2) Reduce the personal financial investment necessary for development

There are different ways to incentivize involvement. But let’s think about open source software. People aren’t paid anything to contribute, and yet the body of software that has been developed is enormous. Look at Linux and Apache. Both have enormous market share—Apache in the realm of 70% (don’t quote me on that). Why? Well, first off, it’s free. But not only is it free, it’s constantly improving. What motivates people to contribute code? As Yochai Benkler put it in his TED talk on the matter: "Money isn’t always the best motivator…if you leave a $50 check after a dinner with friends, you don't increase the probability of being invited back. And if dinner isn't entirely obvious, think of sex.”

His analogy draws a hearty laugh from the audience because they know it’s true. Just because you give someone money does not necessarily make them want to do it more. On the flip side, you could say that they are simply not getting enough money. But the point is that there are things that people will do just for the money, and other things people would choose to do for free because they enjoy them. In the latter category is contributing to open source software.

It’s a task that, when farmed out to a large number of people, is nominal work for each person, but they get the satisfaction of contributing to something greater and working with a community of like-minded people. Additionally, contributors will likely be developing something of interest to them, and can each benefit from the community product. Perhaps Ganesh Prasad of Linux Today puts it best:

“Metaphorically speaking, each programmer contributes a brick and each gets back a complete house in return. In software, unlike with physical goods, one person's gain does not come at the expense of another because a copy does not deplete the original in any way. Sharing software is not a zero-sum game, and there are tremendous efficiencies from participating in such a cooperative endeavour.”

The contributors have numerous non-financial incentives to participate, and their participation does not detract from their lives in any way. The time they spend doing it is enjoyable and gives them a chance to help a community, enriching their lives in both that sense of fulfillment as well as being able to use the end product.

But that’s software. So what’s different about open source hardware? Well, the design process can be free and collaborative as with software, but the prototyping and manufacturing of the final product, being tangible, will cost money. As individuals, or even as small groups, it might be difficult to print circuit boards and conduct the prototyping process that is so essential to open-source hardware development. But collectively, it might be worthwhile to have prototyping resources available just for developers. And then the open source hardware community could grow and flourish as much as the open source software community currently does. How would this work? Who will make this investment? Matt will speak to these questions in Open Source Hardware, Part 2.