Yeah yeah, ok I promise after this post I'll actually finish some of the schematics I've been talking about. But first since I got so many emails about it, I wanted to take the time to write out what the complicated little boxes, stars, and arrows diagram I drew up with Justin's help actually meant.
In the meantime, I've gotten a fair amount of emails and seen comments on other websites in the spirit of, "what's in it for the bank?" and "I don't get it, where do you make money?" I find these questions funny, because I think a lot of web 2.0 guys and "entrepreneur" types are so programmed to think "how can I make a quick buck off this" that they're missing out on the whole point: building a sustainable ecosystem for Open Source Hardware (ok, cheese alert, but really)...
On the flip side of things, a different kind of skeptic would be saying something like, this could be a really bad pyramid scheme. I beg to differ... Actually, I think a lot of pyramid and ponzi schemes happen because somewhere along the process there's this big question mark or black box, and there's a difference between the "marketing" and "reality." I think Open Source shouldn't have a "behind the scenes," so I'm describing the whole Open Source Bank model here to make sure it's sound, anyone participating knows how it works, and it can benefit from other ideas in a public forum. Sure, rip it off, I don't care, because I'm not worried, because there aren't any hidden spots for statements like "and then we'll skim x% off each one of these until sales go up to 800 billion and then sell ad revenue." I double checked to make sure it didn't :-)
Open Source Economy Equilibrium Reactions
I'm borrowing from my old chemistry text books the concept of forward chemical reactions to explain how I think the bank is an "economic equilibrium reaction."
But first, some definitions of the icons I'll use to explain the equations:
And this is the queue that the squares and markups are filling up into:
Ok, here I go... the simplest reaction is the normal one, "pre-ordering". This is normally what scaling pre-ordering systems involve. On the left side of the equation, someone waits some time (as the queue fills, and then the hardware is built), pays money up front, and pays the markup (e.g. 15%). The reaction balances on the other side, because someone gets a finished piece of hardware. There's an external benefit from the system (externality?), which is that since there's a pre-buy reservation in the queue, there's no chance of getting hit with an "oh no, the product you're looking for is currently out of stock or on backorder please come again in 6 months."
Normally, that would be sufficient, but it doesn't balance, because the end result is a bunch of people paying for a product, and paying markup. Where does the markup go? Someone else, who profits from the queuing. What if there was an option to over-pay, or pay for another to be built (at cost) - aka Buy 1-Build 1?
In this case, the only thing I added was the orange box on the left side, which means paying the cost for another spot in the queue. So now, if that slot is reserved as a "build", then when someone else buys at cost+markup (like equation 1), the buy/builder/funder gets reimbursed the cost they paid, plus the markup from the second purchase. Since there are two markups (blue on the left and orange on the right), you can cancel both of those out to get:
Which is like saying, in exchange for speculating and helping the pre-order queue fill up, someone gets the hardware at cost. One smaller externality, that I didn't include, is the fact that building also reduces the amount of time on the left, so the wait is less for everyone - a system benefit! If the queue doesn't fill up in the stated time period (e.g. 3 months), someone (me) writes back checks or cancels out the Paypal transactions. Sure, that takes time initially, but whatever (the whatever is because if it ever got too big, the small amount of the tail end surplus from the bank would be way overkill to reimburse that if it ever needed to be a full time job for someone).
Ok, what happens if I include a Buy 1-Build 2 option? Now there are two additional at costs on the left hand side, but then the system says that if two other people buy 1 later, that person gets both costs and both markups back:
There are two cost boxes on both sides, so those cancel, and the blue markup spent on the left cancels one of the orange markups on the right. That means there's now one leftover markup on the left... is that profit? Well, you could look at it that way, or - more practically - it's probably going to offset shipping costs. Unless UPS or Fedex start thinking this way too :)
Ok. What if someone doesn't want to participate in the speculation process? In the typical real economy, those people get penalized by having to pay more for something, and early buyers get a discount. Come on... isn't it bad enough I have to wait for vaporware, now I get to pay more for it when it finally comes?! No thanks. In this model, you just wait. And of course the reward for not putting money up front is that when the product gets funded, and built, you get the externality benefit of the hardware being out there for a while, so maybe the kinks are worked out, there's more code for it, etc. On the downside, though, there's a hidden risk that the hardware goes out of stock (e.g. the opposite of the externality in the normal pre-buy).
Ok, now what about making things really really complicated for a second? I swear there's a reason for it... so what about about someone who just wants to fund hardware? Like an individual investor, or venturer. Well, there are some big tradeoffs to be made here. Someone who just invests and helps build is like saying they don't want to actually get a piece of hardware, they just want the return on investment. That's a pure speculator, and would they have no direct stake in the hardware as a tangible object. In a negative light, that person doesn't really care if something works, or is cool, or does something new, they just care if someone else will buy it. Sounds like a venture capitalist. Yuck. But! If there's a tradeoff worked in, that will limit speculation. Instead of just giving a Build-5 investor 5 orange slots, which would pile on each other as the queue grows, the queuing system only gives them 2 pre-slots, and the other 3 slots go into the bank side of the queue. The bank side doesn't get it's cost and markup back until all of the Buy/Build side gets sold. So now the Build-5 types have to think, ok, not only do I have to think... will anyone buy it, I have to think, will someone buy it in a reasonable amount of time?
Simplifying this equation down, it starts to look like a traditional time-based investment finally. If someone has money to begin with, they just sit back, relax, ... and wait ... and then get a return on investment.
But there's an important externality here too. If someone funds 5 only, and 3 of the 5 don't get reimbursed until after all the others Buy/Builds are sold, they have a motivation to make things sell faster. One really easy way to do this with hardware is to write cool applications and share them - e.g. with Open Source Software (ding! OSS+OSHW = 1 point). So now it only really makes sense to fund 5 if someone can do something about accelerating the sales to get paid back. Ok, it's not perfect, probably no economic system big or small is, but at least there's a check and balance that I understand, and I think it's a fair tradeoff in the hardware / software world.
And this brings up the last point, the actual role for the bank. The bank's role is to find a way to provide a system benefit (i.e. achieving scale pricing for low quantities for everyone) while generating some form of return on the investment tied up. In this case, the bank takes up the second half of an order queue, waits some time, and then gets in return the base costs that are bought, plus markups.
This simplifies because you can cancel out each of the square boxes on each side to get a simple reaction, of waiting time to get return. But there were all sorts of built in penalties for doing it at a lower quantity in the Fund-5 model reaction above, so what about this time around? In this case, the bank gets its markup back over time only if the hardware sells. At a 15% markup, that means ~90% of the hardware queue needs to sell before breaking even, and before anyone that put money with the bank starts getting markups.
There are two system rules for the bank. First, the bank's money is pooled, so there's a minor portfolio benefit, because the money would be spread out over a few projects. To counter-act this, anyone that invested in the bank can at any time cash out by buying any funded inventory at cost. That's because a bank note is a claim on inventory, and is a bank investor wants, they forego the markup from someone else, in exchange for the product at cost. Regardless, this means a bank investor gets access to anything built at cost, so this means the investment makes the most sense for someone who could actually take advantage of the hardware. But all the while, they get to share the externality benefit of lowered per unit costs from the scale they helped get.
Return on investment and the momentum principle
Finally, the bank's rate of return on investment. The Illuminato experiment was AJM (Andrew, Justin, Matt)-insured at a 5% minimum return. This is like saying, in exchange for a bank note investor being willing to help lend the money now to buy parts (like a temporary line of credit, actually it really is a temporary loan of credit), we'd be willing to take on that minimum of 5% because a) the three of us wanted more Illuminato's built anyway and were willing to buy it all and have lots of leftovers, b) but based on the number of emails I got, I was pretty sure at least half would sell, c) I thought the worst that would happen is maybe no one wanted to buy one for 15% markup, so the worst case I'd sell them at cost, and reimburse the lenders the 5% markup after they sold. All of this comes down to saying, Andrew, Matt, and Justin "sponsored" the Illuminato project. In theory, this shouldn't be needed after the rest of the model is tested, just as long as the "momentum principle" holds: that because there are 25 people that want something, there will be 25 more people that want it.
And I think that's really what the whole system comes down to: "the momentum principle." I just made that term up, so I'm going to try to define it: "If X people are willing to pre-buy hardware, there exist Y other people willing to buy in the future, where Y is very close to n*X. n = ~90% when markup = 15%."
And this in turn is a lot like saying, the bank is taking a bet on the sustainability and future of Open Source Hardware, one project at a time.
*folds hands in lotus sign, takes drag of peace pipe, passes out to sleep*
I've got lots of pages of notes here, so while I'm waiting for components to come in the mail, I'll write in upcoming posts about: why 15% and how that number gets set, when does a queue start up, this system vs. the federal reserve bank system, and the shipping problem.