Skunk of a Start-up

NDAs gone too far!

I just received an email in my inbox from Bitcasa, that startup from TechCrunch Disrupt SF 2011 that had lots of chins wagging about its Dropbox-killer promise of free ‘infinite storage’ across the cloud.

The email invited me to join the beta program, and so as I had signed up to be put on said beta list, I proceeded to do so. I downloaded the package to my Macbook Air, installed it, signed up for an account using the beta email address, ticked all the boxes, and…

Wait! What does that box that I just ticked say? I agree to a Non-Disclosure Agreement!? I’ve never come across that before when installing beta software, or indeed any software. A legally binding NDA??

That’s a bit much.

Here are the top line points covered in the NDA:

• Actively use and evaluate the product or service being tested
• Provide the types of feedback requested and respond to questions
• Give Bitcasa, inc. all rights to any feedback you submit
• Not disclose that you are participating in this test
• Not show the materials to others
• Return the test materials if requested

The last one is quite the gem, I thought. And before you ask, I certainly didn’t sign up to the beta program, so I am legally allowed to let you know OTHERS ARE LIKELY PARTICIPATING IN BITCASA’S BETA PROGRAM.

If Software Were A Bridge…

Came across this on LinkedIn, and had to spread it around - a little bit more enterprise in its association perhaps (certainly building anything for 10 years departs from normative startup behaviour), however if nothing else, a great reposte to analogy via analogy. Very meta.

“Software engineers truly are a breed apart. Civil engineers talk about designing bridges to last for 500 years. In software we are thrilled if our code can last for 10 years.” 

Now, I understand that this is just a little dig and a funny one at that, but I find its even more funny when we compare apples with apples… 

If a bridge was software, it would be designed and built with an understanding of how many cars it would have to support, the ground it is sitting on, the strength and nature of the materials used in its construction, but that is just version one of the bridge, and thats where things get different. 

It would have to exists on top of all sorts of surfaces. The surfaces would change from rock, to clay, to sand, to mud, to a floating bridge throughout its life, and it would still be expected to work. 

Copies of it would be made all over the world and expected to perform similar task to the original bridge. The original bridge is transformed over time to the point where the original bridge is just a framework for hanging new features over the years. Typically, these new features would be implemented by engineers who had nothing to do with the original bridge design with technologies and materials that were not around at the time the bridge was firsts built. Occasionally, features are added to the bridge while it still open and has to maintain peak capacity. 

The original bridge was made with iron and cement, but throughout the years, engineering materials become more advanced, and new additions are added to the bridge with a variety of materials including alunimium [sic] and carbon fibre, while still maintaining the structural integrity of the bridge. 

Original design assumptions that were considered when the blueprints were drawn up would be invalidated over and over again, and the weight the bridge has to eventually support is 10 times the weight it was designed for. 

The future of the bridge is for it to have wheels and roll up and down the bank based on the peak traffic flows. It works in collaboration with other bridges and has to avoid collisions, and if there is a collision, it has to handle it gracefully and keep detailed footage and logs of the events which is sent via satellite back to remote stations for analysis. 

If a bridge were software, it wouldn’t last 5 minutes letalone [sic] the 10 years software developers get software to work for. 

On the other side, if software were a bridge, it would be built once, run on the same computer with a never ending supply of spare parts, and no new featuers [sic] would ever be added… except maybe more hard disk space once every few decades. 

I guess what I’m saying… Civil engineers get it easy!

Bravo Mr Pond! (Sorry, I had to…)

Omar

Gamification Q&A

I just watched an informative video Q&A on gamification by Gabe Zichermann here. The video is one that I definitely recommend to anyone interested in the subject if you’ve got the time. (Put it on in the background and soak it up via osmosis - go on, it will be worth it!)

It’s of particular relevance as we at MP are currently working busily towards an alpha release of our first idea which will have gamefication at its core. But more on that later.

For those that don’t have the full hour to spare, here’s my takeout:

• For every action/activity, look to make the majority benefit from the game, even if the natural approach would be to deal with the few outliers that are actually pushing the action/activity forward (e.g. speed camera lottery - http://www.youtube.com/watch?v=iynzHWwJXaA).

• Don’t go down the route of giving away free stuff - you probably can’t afford to, anyhow! ;-)

• STATUS. ACCESS. POWER. STUFF. That’s the order of user desire, status being the most desired. (Luckily stuff comes fourth, eh?)

• Consumers know what ‘stuff’ costs; they don’t know the value of status/access/power, allowing for arbitrage opportunities as the market potentially overvalues.

• It’s all about ‘ego-economics’. (Free cup of coffee or priority access to jump the queue?)

• It’s not about the product; it’s about the motivation.

• Bartle’s four player types: ACHIEVER. EXPLORER. SOCIALISER. KILLER. (For more around the motivation of each - http://en.wikipedia.org/wiki/Bartle_Test)

• Don’t necessarily design for all four player types.

• Never limit the amount of money someone can pay you…!

• Give people the option of paying with time or their money.

Easy!

Omar