Werd I/O

TechCrunch reports that IBM bought Aspera yesterday:

Aspera’s software is built on “fasp,” its patented file transfer technology. Fasp is designed to leverage a company’s wide area network (WAN) and commodity hardware to achieve speeds that are faster than FTP and HTTP over a secure network. A WAN is essentially a company’s network across a large geographic region. Aspera’s technology optimizes the WAN through its software that allows for granularity in the way the technology is used. Through the process, Aspera optimizes the bandwidth, latency, bottlenecks and a host of other factors.

Essentially, Aspera is an optimized, proprietary protocol built on UDP. The sender and receiver needs to have Aspera software (or software that licenses Aspera's technology) installed for the transfer to take place.

IBM's thesis that we need faster file transfers is obviously correct. Uploading large data or media files is a pain, and it's not a problem that's going away. While downstream bandwidth is getting better all the time, upstream bandwidth often suffers in comparison - and between big data, more sophisticated applications and our insatiable appetite for video, the size of the files we're moving across the Internet is going up.

[Disclosure: right now I'm CTO at latakoo, a startup that helps enterprises (including TV news networks) move large amounts of media data around. We use a toolbox of compression techniques, as well as a global upload network, to make managing media files much faster. Journalists use us to, for example, upload video from Air Force One while the plane is taxiing down the runway.]

Don't think there's a problem? 5 minutes of recorded video on an iPhone 5 can be 1gb or more in size. Try uploading that from anything other than a super-fast broadband connection.

The trouble is that a protocol like Aspera's naturally leads to lock-in, and can only solve the problem for certain kinds of software. Unless fasp is open-sourced now that it's owned by IBM, every piece of software you own will need to have a license for their patents in order to take advantage of it. Not only does that lead to more expensive software, but it also limits the innovation that can happen around the protocol. If your business relies on fast file transfers, that's a lose-lose situation for you: you're locked into an expensive ecosystem, and there's little chance of a disruptive incomer to tweak and play with the protocol. Because of that, folks will just invent new protocols. When an improvement is made, it's likely you'll have to buy into a whole new ecosystem, as opposed to just upgrade to the next version. You'll hop from lock-in to lock-in.

Knowing that we need to speed up uploads, and use all available bandwidth, we need to think about other, more open approaches. UDP makes a lot of sense as a bedrock, but an open protocol designed for resilient file transfer is needed - and then, with a first version prototyped, we need to seed libraries all over the place, in every available language. We need to design it for backwards-compatibility. And we need to make sure it remains unencumbered with patents (possibly, in today's climate, by defensively registering a patent and then widely granting a license).

Our approach with Latakoo has always been to use standard protocols and optimize the files that are being transferred over the top. That works really well, and ensures wide compatibility with all kinds of networks, from corporate infrastructure through satellite modems connections. Even better would be to be able to rely on a well-supported open protocol that optimizes the upload stream in ways that TCP does not (and then, continue to optimize content with this as a starting point). Bittorrent exists, of course, and is wonderful - but is often blocked because of unfortunate connotations and liabilities relating to media piracy.

Developing such a protocol is in the interests of Netflix, Google, and, yes, Latakoo. Faster file transfers are empowering for every user, and save large service providers money. They're easier to integrate with, and allow for an ecosystem where the customer is in control. Everybody wins.

Aral Balkan announced IndiePhone today. He did a good job of making it sound exciting, in a very Jobsian way:

I think it's great that he's driving interest in the subject, and of course it's fantastic to see anyone starting something up with these sorts of principles. I particularly agree with his arguments about poorly designed open software. I do have some specific questions though:

1. I'm curious about the motivation for actually building a phone. That seems like a very Apple thing to do - whereas for me, an indie approach would imply being able to run the software of my choice on the device of my choice, with full control over data transmissions and storage. It's also a dangerous thing to do, and could taint the water in the same way that Diaspora arguably did for decentralized social networking. The Ubuntu Phone failed, and it had a giant name behind it. Meanwhile, Firefox OS, with a much more handset-agnostic approach, is chugging along nicely.
2. What might the experience look like? Whereas the likes of Apple are very prescriptive, to me "indie" suggests that I should be able to tailor my own experience to a much greater degree than other platforms. For example, the ideas surrounding a people-focused communication experience might work well for a lot of people, while others might want their phone / platform / OS to work another way. Independence means I should be able to choose.
3. I want to make sure latakoo and idno can both run on it. What might that process look like? What kind of software will it run? That isn't clear yet.
4. Why was it necessary to trademark the word "indie" in the context of the cloud and operating systems (as well as "indie cloud", "indie phone" and "indie OS"), given that the indie web is a concept that's been around for years now?

I love the ambition here. But I'd also love to know more, and I'm a little bit concerned that the presentation inadvertently co-opts terminology and ideas developed by existing communities, without involving them in the project.