I’ve come across this blog post a number of times, and it always makes me think. (Wesabe is also notable for having open sourced their code after failing, though it hasn’t gotten much continued development.) Regardless, more companies should share stories like these so others can learn from them.
From the post:
Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data, reducing the number of fields in their signup form, and giving them immediate gratification as soon as they possibly could; we completely sucked at all of that. Instead, I prioritized trying to build tools that would eventually help people change their financial behavior for the better, which I believed required people to more closely work with and understand their data. My goals may have been (okay, were) noble, but in the end we didn’t help the people I wanted to since the product failed. I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach’s ass. (To be defensive for just a moment, their data accuracy – how well they automatically edited – was really low, and anyone who looked deeply into their data at Mint, especially in the beginning, was shocked at how inaccurate it was. The point, though, is hardly anyone seems to have looked.)
Google has a mixed history with their product offerings. Though they were once the poster child of open source contributions and open standards, they are now shutting down well-liked, standards-based services to move users to applications that are more tightly integrated in the Google ecosystem, allowing them to more closely track users and collect more data for advertising purposes. As examples, Google Reader (which used the RSS and Atom standards) was shut down in favor of Google+, CalDAV access was limited for Google Calendar (though I think they partially reversed that decision), and they’re in the middle of shutting down Google Talk (which uses XMPP, the same as Facebook and others) in favor of Google Hangouts. The writing is clearly on the wall for FeedBurner and maybe even IMAP access to Gmail. The idea of Google killing off IMAP seemed far fetched a couple of years ago, but now that “Inbox by Gmail” is their vision for email’s future, it certainly seems possible in a few years. All of this means that Google will have much more control over how and when we can use our data.
F-Droid: The first place to check for an open source solution, it has it’s own “app store” with a wide range of packages. You can even find some apps for free, given that their counterparts on Google Play include a compulsory donation. Unfortunately, it’s missing a “most popular” section, even for those who would opt-in to sharing what they’ve downloaded. Regardless, I’ve found that many people don’t know about F-Droid, and many are happy to know it exists.
Prism-Break: Born out of concerns about government surveillance (e.g., the PRISM project from the NSA), this has lists of open source applications whose code can be audited. It’s not specific to Android; it includes iOS, OSX, Windows, etc. Almost all listed solutions use open standards.
Droid-Break: Inspired by Prism-Break, this is primarily focused on Android.
Should you only use open source applications? Well, it might not be that enjoyable of an experience on mobile today… and although open source matters, open standards might even be a more important distinction to consider as we move more and more towards cloud computing, considering that products will continue to appear and disappear over time. Certainly, if you have a choice between a closed-source app that uses open standards and a closed-source app that uses the opposite (i.e., proprietary APIs), it would likely to be in your own best interest to strongly consider the former, given the long term.
The list of sources is just a starter set, but worth a look the next time you’re looking for software. If open source and/or open standards aren’t on your list of considerations, there might not be much software that use either in the future.
The future of the browser just got a little more interesting. That Firefox and IE are both supporting asm.js is a clear step towards eventual standardization. This development goes to show the cleverness of the asm.js approach over, say, Google’s Dart.
HTTP/2 is based in large part on Google’s SPDY. SPDY did some things that HTTP/2 does not. It required the use of TLS (Transport Layer Security) to enhance privacy and security. HTTP/2 makes this optional; it can operate over TLS or over plain TCP. Some vendors, however, have said that their implementations will only support HTTP/2 over encrypted TLS connections to regain these privacy benefits.
Okay, so some browsers will require TLS and others won’t? No wonder I’m confused. If I were to guess, I’d imagine we’ll see most browsers support unencrypted HTTP/2 in a few years, provided enough of them support unencrypted connections initially. (Who would want to be the vendor of the only browser that’s forced to use the slower HTTP/1.1 on some sites?)
That’s not to say TLS is a bad idea. I just don’t think this requirement will stand the test of time given that it’s already giving way.
Code Rush is a 2000 documentary following the lives of a group of Netscape engineers in Silicon Valley. It covers Netscape’s last year as an independent company, from their announcement of the Mozilla open source project until their acquisition by AOL. It particularly focuses on the last minute rush to make the Mozilla source code ready for release by the deadline of March 31, 1998, and the impact on the engineers’ lives and families as they attempt to save the company from ruin.
It’s interesting to see this in retrospect. The web wouldn’t be what it is today if it weren’t for Netscape open sourcing their browser. It’s also interesting to see how little has changed in the startup community. However, I was surprised to find a good chunk of the film is dedicated to the Netscape developers trying to pay down their technical debt (fixing bugs). If memory serves me though, Mozilla was pretty rough when it was first released.
In any case, it’s free, only about an hour long, and documents some important history of the web, so it’s worth a look.
The BBC has revealed its fiendish side — tricking kids into learning how to code with a free Doctor Who game. The Doctor and the Dalek is available now on Android, iOS, and Amazon app stores, and combines a platforming adventure with an introduction to Boolean logic-based programming.
How unfair that this is limited to residents of the UK.
Today the company announced that it would soon be removing SPDY support from Chrome. That’s because the Internet Engineering Task Force (IETF) has been working to update HTTP to produce HTTP/2, an updated revision of a protocol that has not seen any major changes since its introduction in the early 1990s. […] To reduce latency, it included support for multiplexing—making multiple requests and responses over a single connection, with prioritization for different requests—and for security, it makes the use of TLS compulsory.
Multiplexing and compression just make sense… but compulsory TLS? That’s quite a hurdle for the entire web to jump over. I’ve seen some arguments that there might be free certificates, but I wonder how that would be managed. Without having read much of the working draft, a natural question is how potential vulnerabilities in TLS would be handled over the next 15 years, especially considering recently discovered issues in SSL (POODLE, namely).
Regardless, I guess a server could always fall back to HTTP/1.1. It’s gotten us this far.