Selling nothing is great way to make lots of money.

Vaporware? (Photo credit: Brett Jordan)

I was watching Duck Dynasty. Yes, yes, It’s not real, I know. Regardless, it is pretty funny. In this episode, I ran into a really interesting concept that goes against everything the techie and software developer side of me stands for. In the episode, they had sold a ton of cooking DVDs through catalogues, and had only produced the cover the DVD. The DVD content itself did not exist. They were able to prove a market for the product and only then proceeded to make the DVD to sell. The joke was them running around to produce this crazy DVD that the main characters in it didn’t even realize they were doing.

In other words, they sold vaporware, and a whole lot of it, and only when they new they’d recoup the costs of the DVD did they actually make it. (I’m guessing if they didn’t recoup the costs, they’d have returned the money with some standard excuse.)

Throughout my entire technically inclined life (high school, university and beyond), I’ve been told to despise vaporware. In fact, I think this is why many developers really dislike salespeople. “Vaporware” is more of a dirty word than f*** or s*** in many circles. The only other term I think is equally used as a perjorative is FUD. Yet, in this circumstance, it worked wonderfully – it provided the capital they needed to make the video well, and if enough sales weren’t made they would simply use one of the standard stock excuses you hear and return the money.

It hurts me to say this, but selling nothing is a great way to make lots of money. Note I’m not saying that you should sell nothing and get paid for it, I mean selling something you don’t have yet and use that to raise funds to build it.

Sounds a whole lot like Kickstarter actually. Except, in this circumstance, if you don’t deliver, you will have legal consequences unless you give the money back (and even then.) However, in this circumstance, it’s a lot easier to convince people to pay in because it isn’t a donation, but an actual purchase.

So what to make of this? Personally, I don’t know. I know my team has some amazing ideas for hardware and software, but we don’t have the capital yet to follow through like we want to. Yet, to sell it without already having it built seems somehow wrong, even if the client gets the product in the end (and may even not realize that it was vaporware at any point.)

However, I’ve learned in my life the propaganda and ideologies that have been ingrained in me sometimes are dirt wrong. So, this is definitely something I need to kick around in my head a lot more.

As a rule, I’ve always either sold a product we had, or a service we were ready to provide as soon as the contracts were signed. However, if you were selling thousands of products to thousands of people, and you had a plan to have it ready by the time they expected it delivered, if you got the money, what to make of that? More people will be happy to get a good product and you will be able to continue to sell it after the initial bang.

Selling nothing seems to be a great way to make money and, in the end, make a great product from scratch.

What are your thoughts?

Enhanced by Zemanta

Nuit Blanche badge recap

So, the code will come. I promise that.

I had a fun 24 hours just before Nuit Blanche. I had this crazy idea of taking the SoonCon badge which we  (@saeruaisu, @jjstautt & me) built and programmed in 2011 and seeing if I could up the ante a bit on it. Find a couple of analog inputs, and have my iPhone send data to it in order to allow me to send tweets and other live data to the badge.

@jjstautt did a great job soldering the heads onto the end of a repurposed pair of headphones (sans headphones) and I bought a splitter so I could listen to the data as I sent it to the badge to make sure the computer was transmitting correctly.

Badge connected to laptop for testing with splitter and earphones to hear signal. (dit dit dit dit)

Now, the theory behind how I would send signals was to use the right ear as a clock pulse of sorts and the left ear as the data line. When the right ear had a signal, it meant that the arduino should listen to the left until the right ears signal goes down, if the left goes on for a set period of time (is up and not just noise), then the signal is a 1 and reflect that in whatever code that exists in the arduino software.

This alone was a bit of a pain in the butt. Took me a while to find a sound that the arduino would recognize reliably, as well as get it to not hear noise as the right or left ear turning on. My code is awful, but when I github it you’ll see the generla methodology I used for it. Having a variable I could fiddle to determine the best time to wait for the signal to be marked as on for both ears.

Once I had this in place, I simply made it so the clock pulse would iterate through the screen turning on or off the lights as per the signal. Since the fastest pulse I could reliable send to the arduino and have it receive it was around 0.15s, I could really only get about 8 bits per second to the arduino. When painting the screen, this lead to a refresh rate of approximately 15 seconds. Nowhere near fast enough to simply drive the badge with the iPhone.

Regardless, I trudged forward and programmed in xcode (I will also post this on github) a simple application that would let me draw “HI :)” and “< 3” on the phone as well as a few simple test patterns. Once I was confident that the data channel was solid and, in general, fault free. I went to sleep Friday night. Leaving a wonderful video for everyone showing I had the basic proof of concept working. Yes in this video that is xCode’s iPhone simulator running the badgeduino.

iPhone / Arduino sound modem project “Hello World!”

The next day I decided to continue on with this project, but to get it so I can send tweets effectively to the arduino badge, I would need to be able to send letters to it and not simply draw on the screen one bit at a time.

So, I added a special command where the left ear would send sole signals without the right ear at all to tell the arduino to go into “COMMAND_MODE”. This meant that the next 4 bits would be a command to do something or switch to some other mode of receiving. 1111 meant go back to the start, and 1000 went to what I refer fondly as “TEXT_MODE”. Now, there was intended to be the possibility of sending more commands, but I hit a pain in the butt hiccup which meant my code was too big for the badgeduino.

TEXT_MODE worked as follows. Each letter was 6 bits. This allowed me to have every letter of the alphabet and ! , . @ # . I forgot about the numbers, but by the time I hardcoded all the letters into the arduino code I ran out of usable space on the badgeduino and couldn’t have added them if I wanted.

When 111111 was received by the badge, that meant the message was complete, and that it should start scrolling it across the screen. I programmed a text box + button into the xcode and it worked wonderfully. I could type a long message and it would send it, slowly, to the arduino and it would scroll nicely across the screen.

However, it was at this point that I started seeing bugs appear since I was actually using more space on the arduino for the badge than there was space to store, so the code didn’t quite respond correctly and it would simply crash. I’m betting with some work I could optimize the code and get more onto that board, but at this point it was 6:30 and I still wanted to get tweets working in the xCode.

For the next 1 1/2 hours, I realized how pitiful the documentation was for the newest version of xCode around Tweets. I thought I had something working, but by the time I uploaded it to the phone, it would crash everytime I tried to get tweets.

So I came up with a plan so we could all get going. I would copy and paste any tweets sent to @kjrose so they would scroll across the screen. I got a few people asking me to put things that scrolled across, but it wasn’t as spiffy as having it run live.

I think I’m going to play with it some more for next year. Maybe turn it into a distance detector for @saeruaisu’s and @jjstautt’s phones pointing in the direction they are in from my iPhone making sure we don’t get lost now that I have the communication working.

Perhaps next year we can get some more of these badgeduinos (or build a better one that can handle a bluetooth adaptor so I don’t have to use my fancy, but somewhat noisy channel over the speakers) and get a larger crowd with these plugged into their phones.

Regardless. It was good fun, and I will get the code up hopefully this week. I just want to add some comments so it’s not all entirely badly written in a rush code. (remember I only had 24 hours from when I first got started on the idea to NB.)

Have fun everyone. Oh, and if anyone knows where to get the badge design for the SoonCon 2011 badge, let me know. I’ve very tempted to upgrade it for next year.


Enhanced by Zemanta