Posts by jillesvangurp

Don't panic, use openjdk.

We use the Azul certified builds of OpenJDK. Vanilla openjdk is also an option. I'm assuming Azul may step up their own LTS support. There will be some heavy interest in Java 8 support for some time. Java 9 and 10 were comparatively disruptive in terms of compatibility and really not widely adopted. The jury is out on 11 but it will take way more than 2 months for people to switch to that after it is released. That puts Oracle's notion of LTS in perspective. Beware what you are buying into.

IMHO there's very little reason to use Oracle builds it just exposes you to audits and it is effectively exactly the same stuff as the OSS builds from Red Hat, Ubuntu, or Azul minus a few completely irrelevant Oracle proprietary components. I think the LTS thing, or lack thereof (1.5 years is not LTS, sorry), is going to be an annoyance and the post LTS payed support is probably going to be a joke. Oracle is making increasingly good arguments for permanently cutting any dependencies on them. They've repeatedly demonstrated that they are bad stewards of the OSS they acquired with Sun. Hudson became Jenkins, MySql became MariaDB, OpenOffice became LibreOffice, etc.

I think short term a fork is unlikely but I do think many JVM languages like Kotlin, Scala, Clojure, etc. are already eyeing alternative vm technologies around e.g, llvm and de-emphasizing their dependence on Java. Kotlin has a native compiler in the works as well as javascript based backends and there is the ongoing efforts around WASM in browsers. I think clojure can also target javascript. Not sure about Scala. Then there are things like jruby that are basically just Ruby on the jvm, jython for python, etc. Java itself is becoming a legacy language. I see very little reason to use it and am actively transitioning away from it (and I was a very early adopter).

An OpenJDK fork is less likely. Oracle has demonstrated that it can be nasty in a courtroom, with e.g. Android and Apache Harmony (which was the basis for Android, and got shelved by IBM). A combination of patents, trademarks, and the bogus copyright stuff (IMHO Oracle will ultimately lose the case against Google) makes this less likely for bigger corporations to get involved with.

I would not be surprised to see Oracle initiate some layoffs shortly after Java 11 comes out. This smells like a plan to milk licensing as long as it lasts. Oracle is under pressure from its shareholders to generate revenue and software licensing from their traditional products is rapidly melting away and not quite offset by their cloud stuff or "consulting". Years of customer abuse have given them a bad reputation and this shit is not helping.

So far so good

I replaced my 2012 MBP late last year with Apple's latest and greatest. So far, it works. But even so, the key board is a downgrade. First of all it lacks a bunch of keys that I actually use to make room for a touchbar for which I have yet to find a non gimmicky use case. The keys feel loud and flimsy. And I absolutely hate the small vertical arrow keys. On top of that the specs are a disappointment given that I replaced a five year old, 16 GB, 256 GB, quad core mac book pro with something that is slightly faster (about 30% that I can account for in e.g. build speeds) but has the same specs. I got the extended warranty, so if it breaks, Apple will replace the keyboard and everything attached to it.

Meego could have been the Android platform of choice

I was in Nokia at the time and it got very ugly in terms of strategy. The strategic blunders that set Nokia up for failure started way before Elop nudged Nokia into the grave. I've always seen the man as the symptom rather than the problem. I'd argue the first blunder was buying into Symbian around the time Linux was obviously the thing to bet on in the late nineties. Nokia bet on the wrong horse; just like many other phone manufacturers that no longer exist.

Maemo/Meego was pretty much exactly the strategy that Android followed half a decade later. It was the right thing to do. Nokia was leading in that space and it was by and large doing all the right things technically with in house R&D. However, at the time Elop joined, it had fallen victim to infighting. Anssi Vanjoki, Niklas Savander and other high placed executives had frustrated its roadmap for years at that point to keep the sinking ship called Symbian afloat. Meego/maemo never stood a chance with those people around.

For reference, Android sucked donkey balls at the time. It was slow, it had major UX challenges, and it's only redeeming feature was that it provided an IOS like touch screen experience in a market otherwise dominated by Nokia with doomed legacy platforms. Nokia had rushed a version of Symbian to market with touch screen functionality. This version was painfully bad. To do it, the geniuses in charge repeatedly ignored a little touch screen based OS called Maemo (later rebranded as Meego) which was essentially debian linux with (initially) an X based mobile UI and a modern Mozilla based browser. This shipped as the N770 in 2006 and had Nokia done the obious things around that time, it could have shipped it as a phone OS very soon thereafter years before either Apple or Google and anything decent to ship. This never happened and that was not an accident.

The ipad took another 5 years to launch and this was 2 years before the iphone shipped; 3 years before Android shipped. Nokia's failure was actively working to frustrate Maemo/Meego every step of the way. Multiple projects for launching products got shelved; several got re-purposed to run Symbian instead. Also Operators hated the thought of a non crippled software platform running things like a real web browser, and the full complement of internet communication tools that they could not control. At the time SMS was how you made money, even bundling an email client or any of the common chat clients was controversial. Never mind the audio and video capable Skype that Nokia bundled with the N800, in 2007. And all Meego products that did eventually launch got marketed as 'developer phones' with no marketing to ensure nobody would buy them. It wasn't until the n900 in 2010 that Nokia even did the obvious thing of bundling the necessary hardware and software to turn Maemo/Meego into a phone, a full four years after the N770 shipped. The n900 was deliberately designed to fail. It had less memory/cpu than it should have had, it had a clunky form factor to make competing products like the Symbian N8 look better. The n8 btw, was originally intended to be a Meego flagship phone: guess what happened there. And for reference, the N8 had an Oled screen and a 13MP camera. In 2010. People are drooling over specs like that today. Imagine that phone running mobile linux with a nice new UI, a developer friendly platform, and android compatibility just a simple OSS install away in 2010. That's what Nokia failed to do.

Now Android and Meego are not two different things. They are essentially flavors of the same thing, which is mobile linux. In fact modern Android includes lots of code that originates from Nokia's attempts to make Meego run well on mobile hardware (drivers, kernel tweaks, etc.). The platforms were in fact so similar that until the first Nexus phone shipped, the only way to run Android was on Nokia hardware: the N800 and N810 were widely used for early android development since you could dual boot it into whatever. The hardware just worked because the kernel was essentially the same for both platforms. Also, you could trivially modify any Meego phone to run Android apps with a few components easily built from source using debian linux tools that ran unmodified on it. I've done so. Nokia had the choice to do that from way before Android launched right until the moment Stephen Elop executed the will of the Nokia board to never allow that to happen. The reasons for this essentially boil down to arrogance, not invented here, and severe & chronic lack of vision throughout senior management. This is what sank Nokia.

Elop actually did a few things right when he joined. He correctly identified the guilty parties and most of them were gone within months after his appointment. Then he killed Symbian, which at that point was sucking up billions in R&D without much hope for ever earning those back. But then he was of course hired to push through the windows phone agenda and he started removing obstacles for that. Killing Symbian was at that point long overdue. Killing Meego on the other hand was a strategic blunder. And killing it's secretive little brother Meltemi was bordering on criminally insane. Google is still trying to execute the strategy with Android Go that Nokia had for Meltemi to ship mobile linux on dirt cheap phones. It got shot down within months of the first product launches.

Of course Microsoft incompetence sealed the deal. In retrospect, outsourcing the demise of Nokia to MS was genius. Nokia essentially got payed to not have to deal with that. MS itself victim of major leadership issues never really figured out how to run a phone division and pretty much strangled it's acquisition from day 1; they never even tried to make it work. The layoffs started right away. To add insult to injury, HMD started shipping only last year and grabbed more market share than windows phone ever had shipping generic android. HMD leapfrogged anything MS did with windows phone in just a few months with nothing more than the memory of a brand name and a couple of generic Android phones made in China.

Last I checked there were some issues with file system related weirdness still. Particularly symbolic links that are used a lot in many linux/mac based developer tools (e.g. node.js) are problematic because NTFS has no such thing. I know at least one developer that 'upgraded' his laptop to run linux properly after messing around with half broken stuff for ruby, docker and node.js on windows. It just wasn't ready for any serious full time use as a developer environment for him and working around the issues was a major distraction. All that in principle should be fixable for MS but fundamentally raw NTFS just doesn't cut it for more complicated things that just work on linux and mac file systems. The hacks that you need to use to work around that can cause a lot of headaches as well. OSX has its own quirks of course but it has been a known quantity for a long enough that most relevant OSS just supports that as a build target and first class supported platform. If it doesn't work on a mac, it's basically not likely to be very mature, stable, or widely used.

I'm still on a nice mac book pro that has served me extremely well for nearly four and a half years now. Quad core, 16GB, SSD, decent setup in other words. I'm not aware of a lot of windows based alternatives that I could have bought that I'd still be as happy with using today. If the new macs weren't such a downgrade from what I have (crippled keyboard, no ports, same max memory), I'd have already bought one.

What sold me on macs back in day when I gave MS the middle finger after years of appalling performance, crashes, and corporate bloat ware was not OSX itself but the fact that it is a UNIX derivative that runs essentially everything I need and care about for server development, has a decent enough UI that works out of the box without endless tweaks, driver installs, reboots and configuration, and comes with a nice quality hardware package. With recent improvements in docker support, my workflow has gotten a lot better even. I can basically just launch our production docker images on my laptop in a terminal; or build them locally from scratch for testing and development.

Crucially, docker is also working pretty well on windows these days but mounting docker volumes you still hit NTFS limitations. MS needs to come up with a fix for that.

won't affect a lot of people

So basically the java bug is that it doesn't properly validate DTD urls embeded in XML that is parsed with the java xml parser, which may cause it to blindly attempt to open an ftp connection to an smtp server if you abuse this ultimately opening you up to sending spam. So, maybe don't run an open smtp server and certainly not on your app server. Certainly would be nice for Oracle to patch this up but I don't think this will cause a lot of people to panic.

Running an smtp server and then not setting it up properly is in itself a bad idea. Honestly, you are better off using any of a wide range of hosted email solutions for programmatically sending email. Without an open smpt server on a known address, this is going to be hard to exploit.

Git is sort of a baselevel of sanity these days. It's not perfect but it sort of integrates with all important build tools, everybody can work with it, and it does what it needs to do. There are a few similar version management tools out there that you might legitimately argue are good alternatives but stuff like svn, perforce, and cvs are not what I would consider a sane or even defendable choices at this point.

It's very simple: either you care about version management and you use something decent or you don't and you might as well use something decent. There are very few technical reasons to stick with legacy version management technology beyond "we can't be bothered to give a shit".

Usually when you encounter those, the organizations that use them tend to have loads of other issues that all revolve around having a lot of technical debt; usually fueled by years of mismanagement.

Not the most attractive work place in other words.

I actually double checked whether there was any reason to get concerned for me. Turns out there isn't, of course. I'm using Jackson, like most java shops would. Turns out, all the supposed problems boil down to issues handling UTF-16. Simple suggestion: don't do UTF-16 and if you do, do it properly. The spec says json is UTF-8, no matter what individual vendors (cough MS cough) pretend. If you do insist on UTF-16, just configure the damn Reader and Writer correctly and don't rely on default encodings, ever (there is no such thing). The rest of the issues are essentially variants of things failing to NOT parse instead of failing when using comments. Arguably this is a feature, not a bug.

So basically bog standard JSON without any encoding weirdness and comments, will parse. Every time. If not file a bug.

So this story is basically that somebody found some interesting edge-cases with several parsers. Somehow this snowballed into this bullshit. Some of these issues might legitimately be filed as bugs (e.g. the bash parser crashing). But most of this will likely fall in the 'meh wontfix' category instead of the 'OMG INTERNET IS BROKEN' category. The world is in fact not ending and there is zero reason to switch data formats, upgrade parsers, or even read this article, over this for the vast majority of the supposedly user base (world + dog).

I have a nexus 6p. If you strip away all the marketing hype, basically the pixel is a slightly better version of that; nothing fancy and not nearly enough for me to consider upgrading. It's evolutionary design. It's decent phone but nothing special in terms of hardware.

They fixed the distribution issues they had by offering the phone in more channels than just Google's playstore. That's not revolutionary, it's just what you need to do to sell phones. I'd say Google has less to negotiate with than say Apple had when it introduced the iphone.

This does create a problem for vendors in the sense that Google just raised the bar for shipping a decent flag ship product; which as it turns out is not just hardware but also software.

The real issue here is the broken way of distributing software updates in the Android OEM world. The reason I have a nexus is exactly this. The OEM as a gatekeeper for critical security fixes has proven a disaster. They can't be bothered, ever, to ship anything in a timely fashion. Google bypasses both OEMs and operators and ships software updates directly. Franky, anything else is hugely irresponsible these days. I'm sort of waiting for the lawsuits over phones that were hacked because some vendor cock blocked a critical security update. I'd say you'd have a pretty strong case filing for damages if you got hacked this way.

Google leapfrogging OEMs with proprietary software serves a clear goal: to solve this problem. With the pixel phones, the os, add ons, and associated updates come straight from google. There is no licensed distribution that vendors get to tweak. Any and all vendor tweaks are deployed via the playstore.

The real deal is going to be the VR ecosystem that Google is building on top of the Pixel. This is a Google exclusive and Google is planning to control the software stack around it end to end. This is not going to show up in some craptastic vendor mutilated version of Android, ever. Google seems to be announcing that is done supporting that.

So, what comes next is obvious: they are going to 'allow' OEMs to do the same and ship their custom crapware via the app store only where Google gets to review it and act as a gatekeeper. Most OEMs won't have a choice and probably this is going to end up being hugely better for end users.

Relying on HTC for the pilot product makes total sense here since they were dead in the water and probably had no other option than to play by Google's rules. Huawei declined to do so and all but shut down its US presence after essentially failing to roll out its own high end line there. So, they'll end up looking rather silly. All these vendors are talking about "adding value" but the reality is that they all are stuck peddling rather dubious software value on top of generic and outdated android. Their real added value is in the hardware but without the full software value straight from google it is always going to feel like a second rate thing.

The real question is if Samsung will buy into this and if not what will happen to them. My guess is they are far from eager to hand control over to Google. They have their own alternatives for ai, wearable tech, vr, etc. They also have Tizen. So far that has been reserved for the low-end and non phone devices. My guess is that we could be seeing a highend Tizen device soonish. Samsung has always been good at doing multiple things and historically has also bought into other ecosystems when it suited them (e.g. windows ce, windows phone, even Symbian I believe). So, I wouldn't be surprised to see them doing both just to see which one wins in the market.

Latest company to reinvent their own reinventions of IRC. Seems like chat has not moved forward in a meaningful way since the nineties. Every few years some company confuses the latest fad in UX with a need to come up with yet another proprietary, non federated chat protocol that implements some subset of what IRC has done for decades. Time to standardize this shit and move on instead of reinventing the wheel every two years. Mobile seems to have moved the field backwards with dumbed down UIs and nobody even pretending to connect to other networks even. The ONLY reason SMS lingers along is because the IM world is hopelessly fragmented. I'm active on at least half a dozen different chat networks and I still need to fall back to SMS with some people.

Developing your own OS kernel is not a business choice to be taken lightly. Just look at the github statistics for the linux kernel to see what you are up against in terms of change happening there.

The simple fact is that it is pretty hard to compete with linux on features, performance, hardware support, etc. without investing huge amounts of resources. For most companies shipping hardware this does not make sense at all and hasn't for most of this century. Microsoft and Apple seem to be holding out so far maintaining their own kernels at great cost. From a functional perspective it seems to buy them very little other than a walled garden that keeps users in and hardware out. Apple sort of ships their own hardware so it is less of an issue for them since their profit margins are so obscene they can literally budget billions for software development. Microsoft on the other hand has had a hard time getting manufacturers to ship windows on things that are not PCs and needs to recover their R&D expenses through licensing and OEM, and SAAS business models. It seems that on mobile they have all but given up on shipping their own OS and on servers they've been embracing linux as well.

So from that perspective, Fuchsia having its own kernel doesn't make a lot of sense to me. It needs to be more than a little bit better than Linux to make sense at all for Google or any OEMs. And if it is so shit hot that it's actually worth the trouble, you'll have Linux kernel developers all over whatever it is that makes it so much better to try and emulate whatever that is. There are way more full time linux kernel developers than whatever resources Google is able to allocate to fuchsia kernel development and they've been at it for decades. So, I don't see how Google can carve out a niche here with yet another OS kernel that isn't Linux.

More likely is that this is yet another Google project in the category of "lets see if it will stick even though it probably won't". Google is quite regularly retiring things that have been announced with lots of press just a few years earlier. The lack of marketing around this means they're not convinced about this themselves yet.

The only thing that is certain here is that no single court decision will end this. We're looking at endless litigation here. Both parties have a lot of stamina so none of this will have any real consequences any time soon. The real question is when and if they will settle. Oracle clearly still believes it is worth the trouble to continue this and Google at this point is probably just going to let this escalate on principle if only to discourage others from doing something similar (e.g. Microsoft). Both have some pretty good lawyer teams on this so I'm sure there's a case to be made for both strategies. However, Oracle is the one that is going to feel the heat from share holders if the legal bills continue to pile up with nothing to show. So time is not on their side.

Meanwhile none of this will have any impact on Google's roadmap or what remains of Oracle's (or rather Sun's) once big mobile Java strategy. Google has already made the necessary moves to engineer around this by removing its dependence on the former Apache Harmony (the copyright of which is what this court case is about). This was done mostly non legal reasons: it's been retired years ago. Google simply dropped in the GPL 2 openjdk code. Problem solved.

So any court case outcome will be about compensation related to supposed damages with no longer shipping, obsolete versions of Android. So, forget about Oracle succeeding in e.g. blocking products currently in the market, or forcing some sort of licensing deal where Google pays them for whatever. Not going to happen.

Utter BS.

Regardless of the outcome of the court case, Google has already implemented the fix, which involves replacing the Apache Harmony implementation of Java with Oracle's own version of Java, which they license under open source. Of course that kind of requires the whole thing to stay open source since Oracle's Java is licensed under the GPL. This was actually an easy fix for Google and actually has a lot of technical benefits since Apache Harmony is a dead project since IBM pulled out years ago and openjdk brings improved language support for java 7,8, and soon 9.

So, whether or not Google chooses to further lock down the Android platform has nothing whatsoever to do with the Oracle court case. There is certainly no technical or legal need for this. They probably will do it anyway simply because it is consistent with what they have in any case been doing over the last five years and because most OEMs do a pretty poor job of maintaining the code they fork from Google. This has been an issue for years and I'm sure Google is working on solutions for this.

The whole API copyright thing is interesting but might end up being a double edged sword as well for Oracle since they probably have more than a few in house implementations of things open sourced by others; including more than a few they inherited from Sun. So, the status quo of APIs not being copyrightable might actually be preferable to them as well. I predict that they will settle out of court eventually.

IDEs still matter

As a long time Java developer, I find it extremely ironic that the primary tooling for developing in languages other than Java is typically a lot more primitive than what java developers are used to or indeed provided by Jetbrains and written in Java. Whether you are doing javascript, ruby, or go, Jetbrain seems to be the go to provider for a decent IDE for those languages.

That's why Kotlin is such an important language because 1) it is developed by Jetbrains and 2) IDE support is not an afterthought unlike with most other languages that emerged in the past 15 years. Any Java shop can seamlessly start doing hybrid Kotlin/Java projects and expect things like cross language refactorings to "just work". It's essentially a better Java and unlike other languages you don't actually have to compromise on tool quality.

The comparison with Scala is interesting. In my view scala is sort of what C++ was in the 1980s: a little bit of everything that seemed cool at the time integrated into a monstrosity of a language. Like C++ you can do cool things with it and like C++ there's an awful lot of completely unreadable code being written by people who confuse every problem out there with a nail just because they have a shiny new hammer. Kotlin is sort of the reality check that scala has needed for some time. If you are doing Android, Kotlin is a no brainer.

There's much more to it. Installing and starting elasticsearch with no data is easy (untar, modify config files, run it). Automating that buys you very little. This is where the article above stops.

Hardening the setup, with snapshot backups, on deploy restores of said snaphots, and the ability to perform automated in place upgrades (i.e. rolling restart), monitoring, elasticsearch curator, etc. is where things get more interesting. Anything else just sets you up for manually managing your cluster for its entire lifetime (or epic failure the first time you mess it up).

For the record, we have a setup such as I describe. I can fire up a cluster of any size with our testing data restored in AWS in about 10 minutes with a single command. We use this a lot for development and integration testing as well as maintaining our production clusters.

The premise of this article is that Oracle gained some level of control over Android. This is nonsense and it is based on a poor understanding of what really happened. 1) Google forked Harmony long time ago and it turned into Android. Harmony was a drop in replacement for Sun's java 5. OpenJdk is a drop in replacement for Google's Harmony fork 2) Oracle has an ongoing legal case against a limited set of Harmony related APIs. 3) Google just replaced these APIs with perfectly legal forks of OpenJDK. This means that this case is now about no longer shipping versions of Android. Still valid but Oracle will likely settle out of court eventually; if Oracle actually manages to make its legal case enough to ever get there. At this point Oracle is probably pissed off and angry; but who cares. Google is likely in no mood to give them anything for free. Their future product line is secured and disentangled from Oracle's looming legal case.

The GPL license does not prohibit Google forking openjdk (rather the opposite) neither does it put Google under any obligation to take over any upstream changes from IBM, Oracle and others. So they have no direct influence over Android. Nor does it obligate Google to actively contribute back to the OpenJDK project. It merely obligates them to provide modified source code under the same license that it was licensed to them, which they have been doing with Harmony as well. So the only thing that changed is that Google forked OpenJDK instead of Harmony.

They may choose to grab some recent goodies in openjdk, and they are probably considering to join the openjdk project properly to further their own agenda there. However, the success of Android is largely based on Google ignoring Sun's JCP and its J2ME cluster fuck and doing their own thing while the rest of the mobile industry was stuck in design by committee limbo. I seriously doubt this will change anything.

Nonsense. Chrome OS is a glorified browser with a linux kernel. Android is a linux kernel with an SDK, an actual app ecosystem, broad vendor support, etc. And it ships with Chrome. So anything that can run on Chrome OS can be quite trivially supported on Android as well. Which is why Chrome OS never made sense from the very day it launched. Now that Microsoft is back in the game of shipping OKish software again, the market for crippled cheap laptops is drying up rapidly because you can get a similarly priced laptop that is not crippled. As soon as you add touch to the mix, Chrome OS just isn't good enough. This is why Google's latest hybrid laptop and tablet, pixel c, already ships with android.

The main problem with Android security is the tiered update model where Google ships an update, and vendors procrastinate and eventually may or may not ship a patch to their misguided adware and malware ridden Android reinventions that may or may not include some of the updates, on some devices that they sold recently. Blame the vendors and not Google for basically not giving a shit about their own products and its users. With Chrome OS, any deployed systems auto update. Google should defiinitely fix this even further; though effectively play services continuously update any android installation for most of the relevant user facing stuff for anything Android 4.x. For example my nexus 5 received the new Google launcher before the marshmellow update since that is managed as part of the play services. The same is true for Chrome and lots of other stuff. Also, most of the Android security problems relate to features Chrome OS simply doesn't have. So it is secure because it is crippleware, not because it is inherently better through some magic design. Also since it has only a tiny marketshare, people are not actively trying to breach its security. So it is secure because hackers can't be bothered, and not because it has some technical advantages.

Don't run elasticsearch on a public endpoint

This only affects people that somehow didn't get the memo that it is an extremely bad idea to run something like a database, or indeed elasticsearch on a public port. Seriously, don't do that, ever. If you do so anyway, you'll at least want to put in place some security like for example an https proxy + basic authentication.

If you don't do that, this hole in the API is the least of your problems and you are trivially exposed to people crashing elasticsearch with a few nasty queries, filling up your disk with some write traffic, killing all CPU by sending some expensive queries, or stealing all the data you have in Elasticsearch. If all that is fine with you, then yes you also expose yourself to remote script execution. In a controlled environment, scripting support in ES is still useful. They are similar to stored procedures in a database.

I'm hearing criticism but I'm not hearing pragmatic solutions to real problems. Systemd may not be perfect but I for one have seen just a little bit too many poorly crafted init.d scripts lately. So, I totally buy that something needed to be done. If systemd sucks so much, what's a real competitve alternative (as opposed to sticking with the horrible script hairball that is init.d)? Upstart might have been it but it seems Ubuntu is walking away from that. This might be a bad case of the before mentioned grey beards being part of the problem instead of the solution. Incidentally, the linux way has always been to quit moaning and start coding. If you don't like something: get organized and fix it. This has always clashed with the if it aint broke don't fix it mentality but it seems that enough people agree init.d is broken enough that it is worthy of fixing now (finally). I've not bought in to Systemd yet either but I won't be sorry to see init.d go. I'll shed no tears over that one.

Having worked there until a bit over two years ago, I agree that Elop does not deserve the full blame. A lot of the problems he was trying to solve had their roots in well over a decade of bad decision making. S60 was a mess. The R&D organization was way too bloated. And there was a severe lack of a vision for the future. Having a banker (OPK) with no technical vision whatsoever in charge since 2006 before him did not help either. That being said, a couple of rather big bet the company style decisions happened on his watch and he pretty much got all of them wrong.

First he underestimated how long it would take to ramp up windows phone sales and how hard it would be to partner with Microsoft. After a flying start, basically Microsoft ripped the carpet from underneath and did the non backwards compatible windows 8 release. He couldn't predict that, but pulling off a major reorg and shift to windows phone was always going to take a 2-3 years. Anything else would have been delusional. As it is, the Lumia 1020 last year came more than two years after the early 2011 announcements and his late 2010 appointment. Arguably that was the first Lumia product to get really excited about. The Lumia 500 (which proved to be a major money maker) was launched around the same time.

Second, he killed Meego, and then later the mobile linux based successor (aka. Meltemi) intended to replace S40 in a market that was clearly favoring mobile linux based platforms such as Android. This cut him loose from doing a Android compatibility layer on either, which would have been technically feasible with little or no R&D. By the time Nokia did finally release an Android phone, it was merely a me too style release that didn't really add value. Getting out of mobile linux was a big mistake given the huge headstart Nokia had on others in this space and given where the market was clearly going already. All they had to do to make it work was to do what Amazon, Samsung, and Blackberry did: make Meego (or Meltemi) run Android apps. Not rocket science given that all major components needed for that were actually ported already. Elop killed two perfectly good, nearly product ready platforms for no good reason than removing competition for windows phone and burned several billions worth of prior investment in both while locking himself out of the only portion of the market that was actually growing. In so doing, he threw away the baby with the proverbial bathwater.

Third, he underestimated how quickly S40 was becoming irrelevant. He needed a replacement and he basically bet on windows phone. Ultimately with some success but he killed the sub 100$ S40 market in the process and gave it to Samsung and others. Killing Meltemi did not help of course. And the later introduced Nokia Android was both rushed to market and too little too late.

Fourth, he underestimated how quickly S60 would sink. A little published fact is that killing it was a hard requirement that came out of the microsoft deal. However, Nokia payed a big price in the form of an essentially overnight irrelevant S60 strategy that was still supposed to pay the bills for a few years. That revenue disappeared overnight.

Elop literally bet the company on this deal with Microsoft and arguably burned several magnitudes worth more in existing assets and investments than he recovered with the ultimate sale to Microsoft (5 billion $) while simultaneously decimating revenue. Ultimately, he bet wrong and he destroyed billions of investment and market cap.

All of these big decisions are on Elops plate. He did a few things right as well. Getting rid of the whole S60 org was a necessary evil, particularly its bickering senior management and its insane black hole style R&D cost: billions went in, nothing but bad products came out. There was just no justification for keeping that going and in fact the decision had been several years overdue. OPK was the wrong guy for the job from day 1 and the rest of senior management had too much personal ties to the failed S60 strategy (and honestly this was obvious by 2007/2008 already). Elop did what had to be done quite swiftly and it really did remove some organizational congestion. I would say this was actually the key reason the board looked for an outsider when they appointed Elop. They needed somebody to cut loose the dead weight fast. Also, the initial Lumia releases were delivered in record speed (for Nokia, and probably the industry) and were pretty solid products (despite ms related technical limitations).

I'd say the trojan horse label is both false and dishonest. The Nokia board fully knew what they were getting into both when they hired Elop and when they approved the decision to go with windows phone less than six months later. You may reasonably assume that was on the table from the moment they hired him.

10M * 5 = 50M/month or 600M per year in revenue. That's assuming their unlimited deal. Actually most of their subscribers are on the 10/month type deal. So, in reality it is probably closer to 1B /year in revenue, if not more. Not bad given that most western countries are still recovering from an epic recession.

Assume Spotify continues growing, and they could be looking at 20-30M paying subscribers a few years down the line. Add in advertising, promotional deals, and other revenue, and we're talking somewhere in the range of 5B/year that needs to be split between Spotify's expenses, shareholders, and the music industry. Spotify does not have a monopoly on this market and there are other sources of revenue for the music industry including competing streaming media, sales of traditional albums, online sales via iTunes, Amazon, or other outlets, and national licensing companies that rake in tons of cash from the sales of empty harddrives, radio plays, etc.

And of course good artists can always earn money in the order of thousands per gig if they bother to tour. If you are any good, Spotify is a great way to advertise that kind of business. This is a big reason why artists are actually paying to be on Soundcloud, which then gives away the music for free. Think about it: mass distribution is more important for some artists than licensing revenue.

If you add it all up, basically the music industry is not doing bad at all right now and are probably looking forward to healthy revenues the next few years. The fact that little of it ends up in the pockets of artists is not the fault of Spotify but the fault of a largely redundant network of middle men that add little artistic value but still grab most of the cash.

So, the numbers add up: this is already a multi billion $ industry and it is growing. It does change the dynamics of the industry. Being a one hit wonder is not going to be profitable unless it is a really big hit that people will be playing for decades to come. However, accumulating tens of millions of plays over time actually does bring in a steady stream of revenue. This favours quality music rather than shit record company garbage that goes out of fashion in weeks. If you are a wannabe musician, online sales is not going to bring in the goods until you are established as a solid artist: you'll have to perform live and convince people your stuff is worth listening to and more importantly: re-listening to over and over again. If you can't do that, why should you be payed?

The problem in the OPK years was that the Symbian team consistently was succeeding in frustrating the obvious line of R&D around Maemo and Meego. Nokia delivered a series of forever promising but crippled developer oriented devices. Not enough memory, slow CPUs, clumsy form factors, business decisions to exclude a phone stack from the N810, etc. On several occasions things looked like they were coming together, but projects were cancelled or converted to run Symbian instead of Meego. That was a combination of politics around Symbian and a near total technical leadership vacuum. OPK was a CEO with a financial background and he probably actually believed Symbian was good enough and a future proof strategy when it was quite obvious neither was the case. There was no real CTO in charge of the technical roadmap. Nokia fired and promoted away several executives to this position but it never amounted to a role that actually had impact. Even today the CTO is actually merely the head of nokia research and I doubt he takes decisions that either Nokia Maps or Nokia Networks care about.

Elop continued the tradition of not really giving Linux any chance whatsoever. He killed Meego based on the notion that it would take years for it to take over marketshare from Symbian. As we know now, windows phone had exactly the same problem. Meltemi was in an advanced stage of development when it was killed based on the notion that Ascha was good enough and that windows phone would scale down anyway. That too turned out to be a fallacy.

Finally Android was always a possibility. People think of Android as an OS. Instead it is just a runtime. It would have run fine on Meego, Meltemi and probably with some effort also on Symbian. Just like it runs fine on windows desktops, OSX, blackberry, and other platforms. Application compatibility is a business choice, not a technical choice. Probably if Nokia had take the obvious decision to support Dalvik on Maemo in 2008 (which ran Android just fine on my N800), it would have had a compatibility story around Maemo/Meego applications and a much smoother transition away from Symbian. The need for that was obvious around 2006 already for anybody in the business with half a brain.

Fundamentally Nokia was plagued by bad business decisions inspired by a fundamental lack of understanding of the technology, user needs, and market. Nokia killed their touchscreen version of Symbian at the exact same time Google bought Android and Apple got serious about the iphone (2004/2005 timeframe).

Merge WP and Windows RT

Apparently, MS is planning to merge windows phone and windows RT in version 9. That would explain the increased attention for RT at this point. Also, WP 8 was about migrating WP to the NT kernel. So, there's a clear convergence going on here.

Actually, it makes a lot of sense. I don't know why this author is bringing up Android as an option that was somehow on the table recently for Nokia. That's not the case and it shows a complete lack of understanding of how difficult it would be for Nokia to port all their software assets (maps, camera stuff, other apps) to Android. That would take years, just like it took years to do on Windows Phone. That never was going to happen. If they had wanted to do that, it would have been much easier to add Android support to Meego. However, they got out of that business two years ago and layed off all the related R&D staff.

Microsoft just bought a growing phone business that is projected to claim the #3 position in the smart phone market this year and that currently holds a solid grip on the #2 position in the overall phone market. There are a lot of people that sort try to portray this as a very negative thing but in reality all phone manufacturers except Apple and Samsung are doing much worse in terms of market share, growth, margins, and profits.

So, that's a somewhat better spending of money than e.g. Google buying the crumbled remains of Motorola for double the money and effectively no marketshare worth talking about at all.

Still the question is valid as to how Microsoft should proceed in merging the two companies. Luckily, Elop has already cut a lot of the dead wood in Nokia and prepared it for this event. Several tens of thousands of people have already been layed off and what remains is pretty well organized (hence the recent turnaround in growth for Nokia). Microsoft never had much in terms of logistics, production, and in the field people that make up much of the 30K people that remain in Nokia. One reason why Nokia was so successful a few years ago is that it had feet on the ground in most countries and good relations with the hundreds of operators world wide. It's the same reason why Apple is struggling in many markets (e.g. China, the largest market for Smart phones): they never had that.

Most of the R&D org is already nicely split up between Asha and Lumia. They can run Asha as is for as long as it is profitable, sell it off as a whole, or properly kill it when the time comes. Nokia has been milking that cash cow for ten years already and recently revamped it to be able to continue to do that for years to come. Samsung is the only competitor in this space for them and the market for this segment is measured in billions of people.

So, this is very different from the past mergers mentioned in the article where there was poor alignment at the organizational and business level. Microsoft got a bargain here. There's plenty of ways that they can mess this up but if they play it right, they'll dethrone Apple as the #2 in just a few short years take a nice bite out of Samsung's business as well.

They'll soon come to depend on the cryptographic currency economy

The genie is out of the bottle. Cryptographic currencies are being used and the amounts in circulation are already very significant and actually represent real life value. If the US government succeeds in imposing any regulations and enforcing them (the big if), it will merely result in the whole thing evolving to counter the ability to regulate.

As it spreads, more people will depend on it rather than officially backed currency. The officially backed currencies are constantly depreciating under the influence of governments printing money to cover their debts. Bitcoin doesn't suffer from that flaw (except for mining, which is a process that is algorithmically controlled and so-far tamper proof). That means, over time bitcoin will become more valuable and stable than real currency. When that happens, the interests of bitcoin users and governments will overlap to the point where the ability or need to regulate it will eventually become very impractical due to conflicts of interest.

It will be of interest to keep track of when the first oil drums paid in bitcoin will start shipping. The combination of capitalism and shady middle eastern regimes pretty much guarantee that that will happen at some point. When it happens, the dollar is history.

Tools go in and out of fashion indeed. There are a few considerations:

1) Is it open source? This is not about getting free stuff but about long term viability of the solution as well as integration options. For example Perforce is closed source, which means it is largely ignored by the OSS community. This impacts you when doing continuous integration, setting up deployment tooling, etc. You'll find few people with relevant experience setting it up or using it. Most IDEs won't support it. Etc. Kind of makes it a really sucky choice regardless of its other qualities. Google chose Perforce when CVS was mainstream and Subversion had not been released yet. It's the same reason Linus Torvalds opted to develop Git instead and skipped subversion entirely (he wanted an OSS solution). I suspect, large parts of Google's code base are in Git repositories these days. As a professional, I steer clear of anything proprietary. I have zero tolerance on closed source components in my software or tool chain. Rarely worth the trouble bothering with proprietary stuff.

2) Is it up to date? When picking a new tool, betting on something that is out of date is foolish. Tools that have become unfashionable rarely become fashionable again. If you use subversion, it is time to look onwards. Git is mainstream now and has a bright future. Btw. Git-svn is a superior svn client, useful when stuck with outdated infrastructure.

3) Is it mainstream or am I taking a bet on some oddball solution? Git used to be the latter but has now become the de-facto choice across the industry. Sometimes these bets pay off. However, most of the oddball Git alternatives failed to get much traction.