So, do you want to disrupt?

Hacking tradtional industries

Some friend of mine once told me that to disrupt you need to make a product ten times better than the available options, as the TechCrunch Disrupt season starts my prediction is that we’ll see a lot of really smart guys trying to disrupt social media or mobile digital photography, or tinker-town. Actually, I believe that there’s actually a chance to disrupt all of them, but those industries have been disrupted several time in the past few years, with BIG players still ruling with iron fist, so why would anyone want to go in that direction?

It’s true that very-complex-unsexy apps don’t win hackathons, believe me, no one want to see a widget that warns you about boring disclosures nor a really useful but kind of complex app to make sense of your social interactions. But no one want to see yet ANOTHER photo app either, at least most of the investors around seems to be very tired of them, I bet that they think like me when I hear someone saying that they want to be the “next facebook“: the cliche industry is in dire need for innovation too. So, by going in that direction you may probably win a facebook-sponsored prize, but you will most certainly use that mini-iPad to work in something else once the hackathon is over.

So what to do? In the last few months I’ve been focusing in industries with high potential and little disruption, the basic idea is: what would be easier to do? A product ten times better than Twitter -a technology based company with lots of innovative inertia- or a product times times better in an traditional industry with less innovation drive like, for instance, airlines? What in theory would be easier to disrupt, the photo sharing industry or the mining industry?


There are some constraints in the economics of disruption: traditional non-technology based industries  are most costly in terms of innovation, you need better ideas with less available information. Ten years ago no one outside the banking industry would had a chance of developing a payment platform, ISO8583 was an obscure protocol reserved to reclusive developers writing code in COBOL, even though the technology was there (SMS banking was starting in India) “10 times better” was a relative term: was it 10 times more secure? Fast? Reliable? Profitable? So you’d need a lot of information before being able to get clients on board. These days, you just need Parse, Stripe and an iPhone and you have yourself a mobile PoS. On the other hand, the costs of disrupting an established technology company are high in terms  of creativity, you need a really good idea in order to disrupt something that is close to the state of the art.

What to do? What to do?

Knowledge is more expensive than creativity, but creativity you can’t buy, therefore knowledge-intensive industries could be free game for the knowledge-hungry. In the last months I have focused my attention in industries under served in terms of innovation, there  seems to be plenty of space for disruption. The travel industry, for example, haven’t changed most since the introduction of discount websites like Priceline or Orbitz, and they haven’t grasped the opportunity presented by social networks. This is the idea behind consumer software startups like The Traveller Commons, a app-based service targeting big niches like the business and solo travelers.

Another industry ripe for disruption in the financial sector. So far, most of the innovation is focused in creating very clever instruments to securitize stuff in dark and complex ways or software to process gazillions of transactions per millisecond, though creative, these are intended to serve companies and make money for very big cats. In this area, decentralized currencies -i.e. Bitcoin– and government-backed digital currencies like MintChip present great opportunities for disruption. There are already some good initiatives like the Bitcoin ATM’s, a securities exchange based in decentralized currencies (DSX) or a payment network for farmer markets based on bitcoin too (Zapan).

Another interesting case in the video games industry. In the past decades technology has pushed this sector to the edge, by improving the user experience with incredible graphics, incorporating AI or with massive online worlds. But in the last few years the inertia seems to be vanishing, mobile games are aimed to casual players for whom killer 3D graphics are a non-issue -therefore most of the characters make Roger Wilco look like Buzz Lightyear in Toy Story 10-, AI is of no use when the game sequence is shorter than a one-way trip on the subway and multiplayer experience is still mostly limited to cow-clicking. It seems that the biggest achievement has been the elimination of the Joystick as the only controller option. So, there seems to be plenty of chance for disruption: social networks are underutilized, multiplayer experience in mobile games is still, in general terms, poor (at least until Rovio comes up with World of Angry Birds), the status-quo gaming experience remains untouched despite the efforts of prominent figures like Ian Bogost or Peter Molyneux, and AI is still to be incorporated into mobile games. Add all this to the renaissance of the indie games movement spiced by the advent of the PS4 development kits, and you can see the opportunities from miles and miles.


As the travel, financial and video games industries there are many more avid for swift and radical change through technological means: mining, food, freight and even the health service industries lack of the appropriate utilization of social and mobile technologies. So when you are ready to develop your next idea you may want to do your homework about any of these industries and get ready to disrupt.


Alternatives to the XMPP stack

So you want to chat?

Let’s face it! Browser-based chat is going the way of SMS: it won’t go soon but it has become a last resort tool when everything else just won’t do. MSN Messenger is gone, and Skype chat is only to let the other part know that you’re ready to start a call, or that your boss just got in. Gtalk doesn’t have a decent app and no one really knows how most of the people in their friends list got there. Even ICQ is struggling to leave the desktop into the app store.

On the other hand, mobile IM services abound, from whatsapp to BBM, iOS Messages, Twitter or Facebook, millenials can’t get enough of those text strings, and don’t want to consign them while sitting in their bedroom desk, but from wherever their most basic communicational instincts assault them.

So, you want to tap into those big instant messaging bucks, and you are all set with your Xcode. So far XMPP has been with SIMPLE the de facto standard for instant messaging communication, but they were created and popularized for web applications, there haven’t been enough pushing by some of the main parties, like Process-One (current owner of eJabberd, arguably the more popular Jabber implementation) that doesn’t have an open API, and have the access to the cloud implementation of eJabberd 3 restricted.

Right now if you want to implement an XMPP client on iOS -and not doing it from the scratch- your best chance is the XMPP Framework, a relatively robust, complex and poorly documented implementation, available in Github under a BSD license. Now, this -or any other- XMPP client require an XMPP server to manage the chat sessions; besides the seclusive eJabberd 3,  there are no reliable (or known) cloud implementations of XMPP servers on the cloud, so if you want your users to chat from your iOS app, you also need to install and maintain your own server or pay someone to do it for you, eJabberd 2, your most probably choice, is a robust, easy-to-install, open source server, that you can install in your favorite Linux implementation.


Enter the aaS

But, if chatting is just a complementary part of your app, and you want to avoid the hassle and reduce developing hours in non-critical features of your product,  or even if it’s in fact a key feature, I’m glad to tell you that you have options.

Cloud-based messaging services provide messaging and cache that can easily provide the required backend for your chat application. Among them and PubNub are prominent. Both provide messaging and chache services, with push functionalities. doesn’t currently have a iOS SDK, so you must connect their REST services using http requests, this means that the token remains visible, something that the technical support team strongly advise against it, instead they recommend to use a server to do the credentialing with the servers and receiving the requests from the app.  Messages are sent and stored until delivered using IronMQ or cached using IronCache, two independent services, therefore if you want your message delivered and stored you will need two http requests to two different services.

PubNub provides a single configurable service, messages can be sent, delivered and stored for short periods of time using a single service, though different features may mean different pricing. Their main services are discriminated into three different categories depending on different approaches, e.g. Pulse is based on dedicated 24/7 unicast connections and measures unique devices daily while Galaxy is based on 1-to-many broadcasts and measures daily peak connections in 1-hour slots. You can use a combination of both in your app and the differences largely disappear when you’re deployed in the global cloud. Thus, the former is ideal for private chat rooms and the latter for public rooms. A single API adresses all the services and features, and there are a myriad of SDK’s including iOS, Android and Windows Phone.

Text, Bytes and Video

However video chat is still king in the browsers, Microsoft bought Skype with the intention of convincing users of using it as a always-on chat Windows 8 app and integrate it to, google hang-outs are still a desktop computer thing -even though it’s moving quickly to tablets- and Facetime works in Macbooks as well as an iPhones and iPads. But change is on the way, a simple search in the Apple App Store in your iPhone will produce a long list of video chat services most of them free. So, why would your killer app must go video-less?

Here you can go several ways: you can go peer-to-peer with WebRTC or expensive but robust like SpiritDSP, there are also cloud based options like Tokbox. I really like WebRTC as a reliable open source peer-to-peer video chat libraries, but most of the iOS and Android implementations are fan fiction that can be found in someone github’s not in the  official WebRTC site (yet). SpiritDSP it’s a full stack of messaging but as you will see in their long list of big corporate clients you’d probably need to charge $99.99 in the app store. Tokbox is a WebRTC based cloud service (WebRTCaaS if you may) with plenty of features like archiving and moderation. The API is very intuitive, extensively documented and supported by fellow developers.

Chat long and prosper!!!

They should all be Hackathons

What does Strata Conference, Government Big Data Conference, GDC 2013, the HTML5 Developer Conference and Comic-Con San Diego have in common? None of those conferences are hosting Hackathons. Even those who seem to be naturally fitted to host one, like Big Data Conferences, are denying themselves the benefits of enabling developers to hack a new spawn of innovative applications to tackle some of the most important problems in the most innovative ways.

I mailed one organizer of a Big Data conference about the chances of the event to host a Hackathon, the answer was not only negative but almost condescending, I felt a little as Guybrush Threepwood, asking whoever gets in front to host a Hackathon. To be honest I’ve been salivating about a Big Data Hackathon for a long while.


Thinking about this post I started looking for some numbers about the benefits of attending or organizing such an event, or about what’s the fate of winners after they go home with their prizes, what kind of traction do they have? How many of them launch? Are VC’s paying attention in a similar way they do to accelerator programs? Most of those questions remain unanswered, I tried looking for the names of winners applications in places like CrunchBase or just plain Google and the results are average, i.e. around 25% of the winners of competences like AngelHack or TechCrunch Disrupt Hackaton are still alive and became companies, even though most of them doesn’t seem to have much traction. For smaller non-recurrent hackathons the available information can’t be considered more than anecdotical. Of course all this is in no way conclusive, many apps may have changed names or spinned, also some of them that seem to be alive may not be still in business, my research stopped at the website, I didn’t try to contact the companies for information. Also there’s little information about those teams that didn’t win but kept pushing for their hacks and eventually became companies.

From the sponsors perspective, it’d be nice to know if the adoption and use of their API’s or services have improved, or if it have helped its brand awareness, to see if they are getting any bang for their bucks. I contacted a couple of sponsors from events I attended but I only came to the conclusion that they’re not paying much attention to the ROI of Hackathons, one of them even gave the impression that they basically treat that investment the same way they treat charities, though it wasn’t clear if it was a philosophical statement or if they actually reflect it like that on the books. One particularly interesting fact is that a number of sponsors are companies that came from Hackathons themselves.

At last, it seems that hackathon skepticism was justified in the Big Data conference organizer, and that my enthusiasm is (for now) sustained only by the awesome experience it’s to attend one, I’m pretty sure that if they could find a way for a hackathon to make sense for them all Comic-cons would have one. This doesn’t means that conferences should stop hosting as many hackathons as possible, even though there’s not enough pieces of information about the dynamics of Hackathonomics.



Are BaaS Killing the WAF?

Some of the common and more used features of Web Application Frameworks (WAF) are (among others) database access, session management and test cases implementations, these frameworks were created with the intention of reducing overhead in software development and decrease the time spent in repetitive tasks by promoting code reusing. But overhead reduction comes with a price: developers must learn to use the framework, and they will usually stick to it due to a steep learning curve, it can take several months to master a framework to professionals levels, specially those required by companies, that once they have a stable platform based on a specific framework, are unlikely to switch. Whether it’s Rails, CakePHP, Twitter Bootstrap, 960, Sass or Django, once a framework inner plumbing is learned developers will evangelize its virtues and demonize other frameworks denouncing their multiple flaws.

If you check into the product description of most of the available frameworks, the words “streamline”, “fast”, “easy”, “reusable”, “less code”, “quickly” are as reused as a cheap sqlconnection string in an old PHP script, there are even those who dare to proclame that their framework provides “commonly used dimensions”, so no wonder that the few skeptics out there will say that easy comes at expense of flexibility and creativity, and it’s not difficult to see why: those “commonly used dimensions” are similarly implemented among the frameworks, therefore not only those applications developed in Rails and Twitter Bootstrap will look alike, but their internal plumbing will be -in general terms- similar to those developed in CakePHP and Compass, even more when hundreds of tutorials available on the web show the even-more-easy way to implement some back-end/front-end configuration, giving a last thrust to creativity by making sure that not only everyone uses a framework, but that most of them uses it the same way.

There is also a usually missed point: framework-specific training has almost no reusability, whatever you learn by teaching yourself Play! will be of little use if you decide that you are better off with Catalyst, and since you need to assimilate a lot of information in order to master a framework the amount of lost effort is considerable if you decide to change platforms.

So the time of the developer seems to be reaching its inevitable end, why learn SQL if ActiveRecord will deal with MySQL? why deal with Java and its hard-to-abstract types when you can name (not declare) variables at will in Python? Can you win a Hackaton coding in C++? Learn yourself some Scala already, you decadent software engineer or prepare to die at hands of a 18 years old Ruby on Rails Hacker!

Or Not?

Back-end as a Service providers will give developers access to specific processes, relieving them of time-consuming setup tasks, without meddling in their workflow. Developers, for example, can use Singly to setup user authentication and session management extremely fast, with almost no non-reusable training (i.e. the amount of information you need to assimilate in order to master the tool that will be of no use if you have to change for another one), the same applies to manage data in Parse, integrate chat with, or provide on-line storage using Box. For most of those services knowing how to access RESTful webservices and manage their responses in whatever language you decide to use is more than enough, nevertheless practically all of them come with a SDK for specific platforms, specially mobile ones, like iOS and Android.

In a personal experiment I created an iOS app that included chat and geolocation capabilities and allowed users to login using Facebook, Twitter and Google. I used an App Design Vault template for the front end, Parse to manage the data persistency, Singly to user authentication and session management, as a chat engine, Google API for geolocation and developed a REST service in pure PHP and set it up in a RackSpace Ubuntu with a LAMP architecture, the whole thing took me a few hours with no previous knowledge of the Parse nor (ejabberd) API and I think that’s pretty awesome! Some may cry foul because I didn’t set a single test case, but that’s something that can be implemented in iOS (or in any other language for that matter) if deemed necessary, and for those worrying about MVC, the integration of BaaS don’t affect the implementation of MVC architectures, if anything, they made it easier to implement from scratch since the number of model-related classes is reduced to a single class dealing with Parse. True, you’ll still need something for the front-end if you’re not creating a mobile app, but the learning curve was gentle and the possibility of shopping around (I could have use Firebase instead of Parse, Engine Yard instead of Rackspace, and Gimbal instead of Google) came at a very low cost.

At this time I couldn’t help to make a comparison: to deploy a Ruby on Rails from scratch for the first time I had to download, configure and install it in Ubuntu -i.e. install cURL to install RVM (and its dependencies) to install Ruby (and Rubygems) to install Rails-, setup Heroku, and face the ordeal of configuring RSpec, Autotest, Growl and FSEvent,  and trying to find out what have changed in the last version so the examples on the book will work, then I had to learn a lot of Rails specific parafernalia, specially to deal with test-cases, where my current knowledge of PHPUnit Test Cases was almost useless. Also some tweaking and fine-tuning of MySQL,a few chmod’s, and Git related routines were necessary. Creating a simple web application for micro-blogging with user authentication and session management with a very simple front-end will take not less than a week if you plan to follow the book tutorial. Suddenly the concept of low overhead took a whole new definition in my mind.

To honor the truth, BaaS have their shortcomings too. Sometimes you must accept some limitations in terms of functionality, and the possibility of hitting the source code in order to make the services do your will is zero, also mashing-up APIs is not always as romantic and adventurous as it sounds, so you may end up doing some extra coding if you want to make the Twilio API to call you anytime someone signed a document uploaded in DocuSign. Finally, many of these BaaS providers are startups working on VC monies (or something similar), in many cases their business models remain yet to be proven, so there’s a chance that your provider of video tweets may not be in business or bought by Google right before you launch, or even worst, that their new pricing scheme will render your bright business idea unprofitable. Some may say that you can win a ChallengePost competition using BaaS but not have a sustainable business model, but I remember also hearing something similar when PaaS and Cloud services were first being adopted. Nevertheless the winds seem to be favoring the BaaS over the WAF: both offer speed and reliability at the expense of flexibility, but BaaS models seem to be easier to adopt, as reliable and less rigid than frameworks.

With the ranks of the “aaS” increasing every year with models like Network-as-a-Service, it’s not hard to imagine an increased demand for services focused on taking charge of repetitive tasks and not on controlling the workflow with a one-size-fits-all approach. In the case of BaaS it remains to be seen if their business models will appeal big corporations the same way PaaS providers like Amazon EC2 did, if so prevalence of frameworks will dwindle if they not adapt, since it will become easier and cheaper to deploy applications using hosted back-end services that each time will act more as almost-ad-hoc solutions that can be quickly integrated to any application. Whether you need online payments, video chat, metrics, or databases there will probably be an API for that, and you’ll be only a few lines of code away to improve your users experience with that shiny new feature that they always kept whining about in the reviews.