3D printing continues to expand at an astounding pace. It seems like new breakthroughs are made on a weekly basis. As the variety and quality of designs continue to proliferate, more and more projects have become ‘replicable commodities’, or goods that can be 3D printed and there are people who want to buy them. Designs like this are extremely important to us, and to the open hardware 3D printing movement in general. In order to encourage their further development, and to thank developers who have already contributed, we want there to be some sort of profit sharing on the external designs we sell. We are calling our first attempt at such a system DevShare.
The fundamental idea is to set aside and allocate some of the money being made by the sale of replicable goods to the people who have contributed to the designs of that good. Ideally, each developer would receive a fraction of this allocation proportional to their contribution to the design. In it’s final form, this would include designers of earlier iterations, or “ancestors”, of the object, though a greater allotment would be given to more recent contributors.
Such a system could give developers and designers an opportunity to spend more of their time designing things, with the potential to make some of money in the process. It would free designers from production and sales tasks, while allowing them to continue releasing designs under free and friendly licenses. Our marketplace is fairly small right now, so designer earnings will be relatively modest. However, as our marketplace grows and if the idea is replicated by other makers and marketplaces, those earnings could increase. Initially, DevShare will serve as a simple “thank you” to designers for their free and open work, but it will hopefully encourage more open source development for 3D printing.
DevShare also has the potential to address some of the issues with attribution and noncommercial (NC) licensing. NC licenses certainly have their place, but unfortunately they are fundamentally incompatible with ‘free and open’, being a restriction to freedom. Therefore any work published with an NC license could never be incorporated into a truly ‘open hardware’ project. People often choose to release designs NC because they want to avoid feeling “ripped off,” i.e., someone else profiting off their work. If an author intends to sell their work, releasing a design under an NC license makes good sense. However, there are often cases where an author has no intention to sell their work, yet a buyer market exists for their product. In these cases, an NC license effectively means “build it yourself, or you can’t have it”, which is difficult for people without access to a printer. Perhaps many of these designers would be amenable to switching from an NC license if DevShare were offered as an alternative.
Version 0.1: Primary Attributed & Thingiverse
Our first iteration of DevShare was done using our sales from August 2013. We manually tracked and tallied our online, in person, and wholesale orders, each one being based off a particular version of a particular design. We used Thingiverse as this version control, presently the de facto standard in the 3D printing community. The major problem with Thingiverse however, is that every new contribution is considered a new design. There are simple mechanisms to show inheritance from one project to another, but they are limited. As a starting point, we’re going to use simply “primary attributed” to do the allocations. The designer who we attribute under the terms of the license (most of which is a Creative Commons license, but we also attribute to GPL, Public Domain, etc) is the person who contributed the specific version of the product sold. This contribution could be a minor modification, or it could be the whole of the project.
There are obvious problems with this method. In some cases, an unattributed original author might have provided the vast majority of the legwork, while the attributed provided some finishing touches (e.g. add a magnet hole). This could unfortunately lead to some resentment, and a sort of competition instead of collaboration. I have some ideas to alleviate these problems, but these will need be implemented in some later iterations.
After the sales were tallied, I earmarked 10% of the base profit of each sale, being defined as the sale price minus the raw material cost. The sale price is what was paid by the person who just bought the product, while the raw material cost includes only things like hardware (plastic, magnets, key rings — but not things like machine time, packaging, incidentals etc). This calculation is designed to align and balance the incentives between makers and developers.
To see the incentives, I use an example of a fictitious ‘smart watch’ which is made up of a printed band (say $1 plastic) and an ipod nano or something (say $99). The total raw material cost for this product is $100. Suppose it was sold for $110.
With DevShare being 10% of profit, the maker profit is $9 and the DevShare is $1. This sale was profitable for all parties. If instead the DevShare were 10% of total gross, the devshare is now $11 — and the maker profit becomes -$1. What was once profitable has now become unprofitable and that sale would not happen. Developers might even be tempted to incorporate more expensive components, knowing this would boost the DevShare — or at the very least, they could be less incentivised to decrease the component and raw material cost.
Similarly, if raw materials included things like packaging and machine time, then makers would be less incentivised to decrease these costs as they cut into the DevShare. These costs are also more difficult to account for. Overall, I think this calculation is the most fair for all parties.
For the month of August, we have calculated DevShare payments for about 15 different makers. The largest share goes to Emmett for a little over $50, mostly for his outstanding and ever popular rotating gears. Initially, we’re putting a cutoff at $5 accrued before payments will go out, which of course will roll over month to month. This week, we’ll be contacting each maker via Thingiverse to initiate the payments and inform them of the new policy. September will be coming soon after.
DevShare 0.1 as it has been outlined here is an experiment I’ve been wanting to try for a long time. I am hoping it will lead to more development in the open source 3D printing world, and I’m looking forward to giving back to the developer community in whatever way we can. There is a lot of potential for 3D printing and open hardware. When combined with distributed manufacturing and a system like Devshare, this potential can be brought to it’s fullest.