Werd I/O

It's traditional to create resolutions for the new year. I've been thinking a lot about where I want to take my work in 2014; these are some ideas.

Write.

Specifically, I want to write more for other people, following from my previous work for the likes of ZDNet, IBM DeveloperWorks and Packt Publishing. I'm also interested in guest posting on blogs and sites around the web, about the social web, #IndieWeb, open source and responsible application development.

Empower independent content creators.

How can we put independent creators on a level pegging with the world's largest media companies? One thing I've been thinking about is that 24-7 news channels are obviously not a future-facing content medium given the web, where you can look up breaking news whenever you want, wherever you want, from whomever you want, without having to wait for a newscaster to restart their 30-minute cycle. Despite the ease of the web, leaning back and watching TV (or some screen) is sometimes pleasurable. Could you create a video newscast that aggregates stories from multiple providers based on your interests and context? Google News meets CNN?

Help support niche communities on the web.

The strength of the web is that we can all publish and communicate with each other, in a variety of different media, and it can all interlink as a single, continuous mesh of conversation and information. Unfortunately, that strength has been undermined by the proliferation of data silos, which make it harder to establish these kinds of links, and also limit certain kinds of content, topics and conversation through conservative design.

There are so many things to talk about, in so many ways, and by limiting ourselves to the platforms that the likes of Facebook provide, and by funneling the value generated by our communities to those sites, we're not using the web to its full potential. I want to help support the full range of communities on the web, and help them be self-sustaining, so that the people who create safe spaces for niche topics can continue to maintain them.

Idno is certainly a part of this idea, and I will continue to develop it as a first-class social publishing platform for both groups and individuals.

Figure out open source for designers.

Open source software suffers by treating designers like second-class citizens.

The open source process for programmers is well-established: we have many different flavors of version control, and the tools that surround them are first-class. I'm as happy as I've ever been working with Git, and software like GitHub and GitLab.

Working with design media is harder. Not only is it hard to represent visual changes using version control, and manage them in a sensible way using our project management tools, but even the accepted file formats for design work are closed. Photoshop comps are the norm, and UX wireframes often use closed software like Omnigraffle. That's because those tools are absolutely the best ones for the job, but standardizing on those formats make it harder to build open tools for design collaboration. And even with this aside, issue trackers are all written with source code in mind.

Collectively, this all means that welcoming designers into an open source community is extremely difficult. Nonetheless, design is an extremely significant part of any software project. It's worth thinking about the first steps towards making this easier.

Build bridges.

It's hard to share from, eg, the Twitter app to my own website, whether it's based on Idno or something else. I'm planning on building a shim that allows me to do that more easily, based on Android's share dialog. But there's more to do. There are ways to take ostensibly closed platforms and find ways to pry them open. For example, functionality to share closed content by email can be used to integrate directly into other, open software. Other integrations are possible, exploiting "growth hacking" features designed to find more people to lock into these platforms.

Work from everywhere.

I've still never been to Seattle. Or Tokyo. Or Melbourne. And it's been too long since I was in London, or Oxford, or Edinburgh. I want to travel more, and use the fact that I can work anywhere there's an Internet connection - and that I am not responsible for a family at this stage in my life - to see more of the world.

If you'd be willing to host me at your office for a few days, wherever you are in the world, let me know!

Wired reports that we're about to lose net neutrality, and "the Internet as we know it":

[...] Today, that freedom won’t survive much longer if a federal court — the second most powerful court in the nation behind the Supreme Court, the DC Circuit — is set to strike down the nation’s net neutrality law, a rule adopted by the Federal Communications Commission in 2010. Some will claim the new solution "splits the baby" in a way that somehow doesn’t kill net neutrality and so we should be grateful. But make no mistake: Despite eight years of public and political activism by multitudes fighting for freedom on the internet, a court decision may soon take it away.

Couple this with the persistent attacks on our privacy and freedom of communication that have come to light over the last year, and we need to ask ourselves if the Internet is still the networking platform that we need.

I don't think it's as crazy a question as it sounds.

When we talk about the Internet, usually we're referring to the protocols and services that run on top of it: the web, DNS, email, and services that sit on top of them, like Wikipedia, Facebook and Google. The Internet is the foundation on which each of these things sits - but it's certainly possible for similar kinds of experiences to be built on different kinds of networks.

This has already been attempted, of course: Internet2 is a network run for academic and research purposes, using many of the same protocols as the Internet, but on different infrastructure. Some 60,000 institutions are connected.

When the Internet was initially designed, many of the things we take for granted were not incorporated into its architecture - most notably, ecommerce, the web, and the widespread communications we now use every day, across browsers, apps and devices. A lot of these services and technologies are able to exist because of hacks and shims. That's a fantastic testament to the resilience of the network, but perhaps it's time to learn from those attempts and build a v2.

Additionally, the current design clearly allows governments and other entities to easily monitor communications, jeopardizing the business and private communication that it's simultaneously revolutionizing. Just as any business that solely bases its products on Facebook, say, is constantly under threat from that company choosing to change its API, algorithms or interfaces, any business that bases its products on the Internet is now under threat from surveillance activity.

What if we could then choose to modernize our global communications by inventing a new Internet, designed to be used by commerce and protect independent communications? I don't think it's enough to bake encryption into its core (although that should happen) - revelations about, eg, companies like RSA using backdoored encryption methods suggest that we should look at algorithms and methodologies that are inherently more secure even when data is not encrypted. Neutrality should be inherent; ownership and governance decentralized.

If creating a new global network sounds daunting, that's because it's undeniably a mammoth task. Nonetheless, I think there's value in looking at the Internet as a proof of concept, as a thought experiment: what could we change to protect ourselves, protect each other, and continue to change the world without interference from surveillance or corporate misdeeds?

As part of the Nieman Journalism Lab's Predictions for Journalism 2014, Jason Kottke writes:

Sometime in the past few years, the blog died. In 2014, people will finally notice. Sure, blogs still exist, many of them are excellent, and they will go on existing and being excellent for many years to come. But the function of the blog, the nebulous informational task we all agreed the blog was fulfilling for the past decade, is increasingly being handled by a growing number of disparate media forms that are blog-like but also decidedly not blogs.

He then goes on to discuss the death of the reverse-chronological stream, as well as the inevitable move to what he calls tightly-bound social media sites. Thematically, it's an interesting companion piece to Anil Dash's seminal The Web We Lost, which was published last year at about this time.

And, despite some hedging on his personal blog, it's clearly true. Almost none of you will have found this link through a feed reader (although my stats show that some of you are using Feedly, Digg Reader, and even Livejournal's RSS feature). Most links will have come through Twitter and Facebook, with a straggling number showing up through app.net and similar sites. If I'm lucky, someone might submit this post to an aggregator like Hacker News.

Note, though, that you're still reading it. The article isn't dying; you can think of the blog, or the stream, or the feed, as the container that the article sits in.

Medium exploits this in a clever way by presenting articles nicely, and then providing a magazine-style site for you to consume them in. Indieweb arguments about whether you should publish posts on a site that you control or on someone else's aside, there's no doubt that Medium's injected new life into long-form text on the web. That's great, and like Facebook and Twitter, you can choose to think of it as a well-executed proof of concept.

If you buy the idea that articles aren't dying - and anecdotally, I know I read as much as I ever did online - then a blog is simply the delivery mechanism. It's fine for that to die. Even welcome. In some ways, that death is due to the ease of use of the newer, siloed sites, and makes the way for new, different kinds of content consumption; innovation in delivery. Jason talks about the ephemerality of Snapchat (which is far from a traditional feed), and there are an infinity of other ways that content might be beamed to us on whichever device we happen to choose to be using at any particular moment. But these content forms are minor details.

The beauty of the independent web is that we can choose to represent ourselves online - and therefore, publish content - in a manner of our choosing. I happen to like the reverse-chronological feed, but if you prefer to publish in the form of an immersive 3D world, or a radio show, or full-screen autoplaying video with annotations, then, hey, that's up to you. It's all part of a rich, interlinking medium. Independence means not necessarily going with the flow.

The counterpart to that is how you read content. In the past, we've been very stream-heavy: RSS readers, Twitter feeds, Facebook timelines, and so on. But there's no need for that to be the case. Part of the joy of a diverse web is that while I might choose to read in the form of a feed or a newspaper, you might want to mash your reading list up in entirely new ways. You could have a robot announcer read to you while you drive to work in the morning (wouldn't that be better than the radio?), or mash related articles up to provide new kinds of content that provide better insight than the sum of their parts. And I can choose to use a completely different form to you. Each one of us can have a completely different experience.

That's a tough concept to get across to an audience that's used to mass media, where everyone consumes the same content in the same form. But we don't need that anymore. Not only can content be personalized, but the form of the content can be personalized. Facebook might agonize over the algorithm that decides which posts are surfaced, but in the future we can each have our own algorithms. Form and content will be separated.

These new kinds of readers will begin to appear in 2014, powered by simple web technologies like HTML and microformats. They will eventually be as easy to use as Twitter and Facebook. And they will make us all more empowered readers and creators, once again connecting us all, but this time on our terms.

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.