Some time ago I published a post titled Kotlin vs Java the Whole Story. It was, by a large margin, the most read and discussed article that I wrote to date.
I was quite surprised by the extent of community feedback because the initial intent behind that post was very humble. I just wanted to prepare an objective ground for an upcoming strategic analysis of Google’s adoption of Kotlin programming language for Android development.
After taking some time to process the community feedback and discuss it with my friends and colleagues, I realized that it will be useful to discuss why JetBrains invented Kotlin and markets it to developers today.
Kotlin productivity myth:
One statement that I often hear and read is that JetBrains invented Kotlin because they weren’t satisfied with Java and wanted to increase their own productivity. This statement takes on different forms, but the underlying assumption is always the same: JetBrains invented Kotlin because Java was “bad” in some aspect.
The immediate conclusion from such an assumption is that Kotlin is much more productive than Java, because, otherwise, JetBrains wouldn’t invest in its development and wouldn’t use it in their own projects.
At this point, it is important that we make a distinction between JetBrains as a company, and individual developers who work on Kotlin.
We, developers, have bad subjective judgement in general, and usually don’t fully aware of the costs of the projects that we are working on. Therefore, individual developers who bootstrapped Kotlin might have very well believed that it is justified to spend several calendar years working on a completely new language for a questionable productivity and performance gains down the road.
JetBrains as a company, on the other hand, is a very successful business. It is improbable that such a serious company hadn’t performed a basic return-on-investment (ROI) analysis before they committed to Kotlin.
When estimated the investment, JetBrains analysts should’ve taken into account at least the following costs:
- Developers salaries
- Salaries of additional non-technical staff
- The cost of effort multiplication on internal projects that tested Kotlin over the years (discussed in Kotlin vs Java the Whole Story article, but much higher because back then Kotlin was even less mature than today)
- Marketing expenses
- Opportunity cost of all the staff involved in the project
Even the most humble investment estimations for such a project would yield numbers in millions of dollars. Maybe even tens of millions.
What were the estimated returns?
From internal productivity point of view, there were probably none.
Even today, when Kotlin is post 1.0, it is not clear whether it is more productive than Java, and if it is, to what extent. However, in 2010-2011, when go-no-go decision about Kotlin should’ve been made, there were absolutely no indications that would allow to perform a quantitative estimation of the impact of Kotlin on developers productivity.
Is it possible that JetBrains committed to an extremely long, multi-million project just because a group of developers claimed that they are able to develop a language that will be “better” than Java and will make them more “productive”?
Very, very improbable.
If we can agree that JetBrains is a serious and successful business, then there should be something about Kotlin that convinced JetBrains analysts and management, back in 2010-2011, that it was a worthwhile investment.
In other words, the answer to the question “why Kotlin” should be rooted in JetBrains business strategy.
I should say right away that analyzing business strategies is not exactly my area of expertise. Fortunately, more than 15 years ago, Joel Spolsky (founder and CEO of StackOverflow) already demonstrated a framework for such an analysis in his Strategy Letter V.
All we need to do is reframe Joel’s ideas in context of JetBrains and Kotlin.
What’s JetBrains business model? They sell software development tools. In particular, their most recognized line of products are IDEs.
What’s the natural complement of IDEs? Right, programming languages. Therefore, it is in JetBrains best interests to reduce programming languages to commodity status.
However, programming languages are very hard to turn into commodity. It is hard because even though most programming languages are free to use, the cost of switching between different programming languages is usually very high. It is extremely hard to convince businesses to adopt new programming languages. Therefore, different programming languages are not perfect substitutes.
From IDE vendor’s point of view, all programming languages are different because they require a support for different set of tools and techniques and might evolve in completely different directions. Therefore, as an IDE vendor, each time a new programming language appears and gains traction, JetBrains need to invest a lot of effort in order to support it in their IDEs.
So, if programmers and businesses entrench themselves in their favorite languages, and support for each new language is a huge PITA for IDE vendor, what would be the ideal situation for JetBrains?
It doesn’t take a genius to figure out that, given the above constraints, the ideal outcome for JetBrains would be to have programmers converge on a single favorite language which is relatively easy to support. And no language is easier to support than the one you develop in-house.
Therefore, one of the motivations behind Kotlin is to migrate developers to a language that is relatively easy to support from JetBrains perspective.
But wait, there is more.
Programming languages are complements of IDEs, but IDEs are also complements of programming languages. We already discussed that programming languages are very hard to commoditize, but what about IDEs?
Different IDEs have different features and different look and feel, and developers usually have strong preferences for specific IDEs. Therefore, different IDEs are not perfect substitutes either.
However, compared to programming languages, IDEs are much easier to switch. For example, some developers who use paid version of IntelliJ at work wouldn’t buy a license for personal projects. If these developers aren’t satisfied with the free version, they can readily use Eclipse, Atom, Notepad++, Emacs, etc.
What this means for JetBrains is that they are always at risk of losing customers because both individuals and entire businesses can decide to use alternative IDEs at any instant.
The risk of losing a market share is especially profound for JetBrains when new programming languages (or new frameworks built using the existing languages) appear and become popular. Different IDE vendors rush to support the new languages, and the IDE market shares for these new languages can end up being very different than for the old languages.
So, if JetBrains is experiencing a fierce competition in IDEs space, and each new language or framework introduces a risk of losing a market share, what would be the ideal situation for JetBrains?
It would be good for JetBrains if existing customers would not be tempted to go for alternative IDEs when new languages and frameworks appear. It wold be simply outstanding if appearance of new languages and frameworks would cause new potential customers to be more likely to choose JetBrains products over competitors ones.
And now answer a million dollar question (probably much more than a million though): if a company X decides to use Kotlin for development, which IDE vendor is likely to be chosen by X?
Therefore, additional motivation behind Kotlin is to increase the market share of JetBrains IDEs, and prevent customers leakage to competitors when new frameworks appear.
The last advantage that JetBrains can get out of widespread Kotlin adoption is easier marketing of their non-IDE tools.
While Kotlin, as a language, shouldn’t affect the choice of e.g. continuous integration server (TeamCity) or issue tracker (YouTrack), the sole fact that developers will use Kotlin and IntelliJ, will probably make it easier to convince them to use additional JetBrains products.
In the long run, by owning a language and providing an entire stack of development tools, JetBrains might “copy” Microsoft’s .NET development ecosystem. If this is indeed their end goal, then, in my opinion, they have a very high chance to succeed in this endeavor.
I don’t buy your proofless accusations:
Based on the feedback from a previous post and many discussion of this topic that I had with friends and colleagues, I know that many readers already feel uncomfortable at this point, maybe even angry. I would like to further explain myself in order to avoid any possible misunderstandings.
Let’s break it into two parts: proofless and accusation. I’ll start with accusation because that’s the more important aspect to address in my opinion.
If you felt like I’m accusing anyone while reading the post, please stop reading for a moment and try to think why you got this feeling. Was it because it looks like I claim that JetBrains invented and promotes Kotlin in order to move their business forward and eventually make money?
First of all, good job understanding the post because I indeed claim that Kotlin is part of JetBrains overall business strategy, and not a tool they developed in order to increase internal produtivity. However, I’m not accusing anyone of anything.
See, I acknowledge the fact that the main purpose of businesses is to make money. Furthermore, as a software professional, I enjoy salaries which are much higher than average. These high salaries are possible only as long as businesses in our industry make terrific amounts of money. Therefore, not only I understand that businesses make money, I also encourage businesses in software industry to make as much money as they can under constraints of laws and ethics.
Furthermore, as an independent software consultant and developer I don’t have an employer which would pay for the tools I use. Therefore, I pay for them myself. IntelliJ Ultimate is an essential tool in my toolbox and I happily pay its licensing fees today, and will continue to pay in the future.
So, no accusations here. Just some dry facts and deductions.
Now let’s discuss the “proofless” part.
First of all, I don’t think that anything in this post needs proof because no accusations were made. In addition, the facts that I listed and the motivations that were deduced from these facts are as straightforward as it can get.
However, for many developers who believed that JetBrains invented Kotlin in order to make their lives easier, the idea that the driving force behind Kotlin is business interests might be hard to accept. Especially when it comes from a random guy on the internet.
Luckily for us, Dmitry Jemerov shared with us why JetBrains needs Kotlin way back in 2011. Among other things, Dmitry stated:
The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEADmitry Jemerov
In my opinion, however simple this fact to deduce, stating it on a company blog is a startling example of openness of a business towards its potential customers.
So, all in all, if you want to know my subjective opinion about JetBrains endeavor with Kotlin – I admire it.
JetBrains committed to a very complex, long term and expensive project, and invested a lot of effort into Kotlin. Then they tested the language on internal projects for years, and managed to slowly build a strong community around it. From business strategy and project management point of view, I think JetBrains did an outstanding job.
Now, be careful not to interpret the above statement as me being Kotlin fan. Even though I respect and admire what JetBrains did with Kotlin, as a developer I’m far from being convinced that actively migrating to Kotlin is a good idea.
Therefore, while it is far from clear at this point whether Kotlin will become a serious player in programming languages league, I do hope that Kotlin will turn out to be financially beneficial for JetBrains.
Let’s summarize what we discussed.
It is very improbable that a project of the size, the cost and the complexity of Kotlin was approved by JetBrains because their developers believed that they can make a language which is “better” than Java.
In my opinion, the main motivations behind invention and marketing of Kotlin programming language are as follows (in descending order of importance):
- Increase the market share of JetBrains IDEs, and prevent customers leakage to competitors when new frameworks appear
- Reduce the required marketing effort for additional non-IDE tools
- Migrate developers to an in-house language that is easier to support
I would like to state once again that I’m not accusing anyone of anything in this post. On the contrary – as a professional, I respect the challenges and the risks that JetBrains accepted with Kotlin project. I’m also happily paying for great tools by JetBrains and other commercial companies myself, and encourage these companies to make money.
What I do want to achieve with this post is to make software developers realize that claims like “Kotlin is good because JetBrains invented it in order to increase their own productivity” are a bit naive.
Maybe Kotlin is “better” than Java, and maybe it is not. It is quite possible that we will never know which of them is actually “better”. What is certain, however, is that the fact that JetBrains uses Kotlin on internal projects has nothing to do with Kotlin’s “goodness”. It is, most probably, just part of JetBrains general business strategy.
So, there is a business strategy behind Kotlin’s invention and marketing, and we should keep that in mind when evaluating a migration to Kotlin as an option.
In the next post in this series we will (hopefully) discuss the topic that I find the most interesting in respect to Kotlin: why Google adopted Kotlin as a first class language for Android development.
Please leave your comments and questions below, and consider subscribing to our newsletter if you liked this post.
15 comments on "Why JetBrains Invented and Promotes Kotlin"
I’m not quite sure I get the point of this article. It was always clear – at least to me – that committing to Kotlin has to have been a viable business decision for JetBrains for exactly the reasons you mentioned.
You fail to mention one point, though: This whole plan wouldn’t have worked if Kotlin was not fundamentally better than Java in a lot of aspects. The whole anticipated ROI for JetBrains hinges on the perceived value of the language over the existing alternatives. You can’t just “slowly build a strong community around” a new language if that language is inferior or just equivalent to the established status quo, because there won’t be any people that are interested. And I assume that also holds true for their internal projects – JetBrains is full of smart people, I’m not convinced they would adopt a new language just because their superiors say it’s a viable business decision.
I’m not saying that everyone should drop Java and move to Kotlin on the spot. There are a lot of valid business reasons to stay with Java for now. But just looking at the languages themselves, I can’t see a single thing that would make me say “yeah, I could understand choosing Java over Kotlin because of that”. And it’s only because of this, that Kotlin indeed was the right business choice for JetBrains.
Glad the business motivation behind Kotlin was clear to you form the beginning. However, in my experience, many devs really think that the sole motivation was to improve their productivity.
I don’t agree with your assumption that the whole plan couldn’t work if Kotlin wouldn’t be better than Java.
First of all, it is too early to say whether the plan worked at all. While adoption of Kotlin for Android is a big strategic win for JetBrains, it is not an economic win because Android development had already been coupled to IntelliJ. Therefore, probably no money earned on this one.
Secondly, your statement about inability to build a community around inferior or equivalent language is based on the assumptions that a) there is some generally agreed criteria for comparing languages b) choice of a language by developers is a rational decision. Point “a” was discussed in the article Kotlin vs Java Whole Story (in short – there is no comparison criteria for languages), and point “b” contradicts the fact that languages constantly rise and fall in popularity.
In my opinion, you also greatly underestimate the power of good marketing.
The last thing is that even though you can’t see a single thing that would make you say “yeah, I could understand choosing Java over Kotlin because of that”, other devs might see good reasons for that. I definitely see some part in Kotlin that I don’t like. This is exactly the subjective judgement fallacy that we discussed in the aforementioned Kotlin vs Java the Whole Story article.
I’ve read the “Java vs Kotlin” article, and it focusses mostly on whether the benefits of Kotlin outweigh the costs of migrating to Kotlin. That’s a business concern, not something that makes one language superior to the other as a language. As I already acknowledged, that is valid and not to be overlooked. However, I am comparing the languages on the basis of “What do people sufficiently skilled in both languages say about them?” – because that is exactly the thing I would look for when I’m not bound by short-term economics, for example when deciding on a language for a new project, or a new language to learn. And although this kind of comparison is subjective and tends to be pretty fuzzy, in the case of Kotlin the picture is incredibly clear – literally every developer I’ve introduced Kotlin to and who worked with it subsequently was eager to tell me how much they enjoy working with Kotlin over Java, how much more maintainable their code is, etc.
Assumption a) I would say holds up – when building a community, that generally agreed criteria is simply “people like it”. That criteria is subjective on the individual level, but becomes objective when you can see from the outside how many people like something, and how many don’t. See above paragraph.
Assumption b) is not necessary because the irrationality is covered by my above points.
Marketing? Yeah, a bit, sure. I’d guess that word of mouth was the biggest factor though, seeing how much people generally want to spread the word about Kotlin.
You say “other devs might see good reasons for that”. Yeah, they might. You obviously do. But in my experience, these are in the minority.
Let me rephrase my point, maybe, because we probably won’t come to terms on what defines a “better” language: The plan wouldn’t work, if people *didn’t prefer* the language over Java. And in my eyes, that’s all that’s needed to make a language better than another one.
I still don’t agree with some of your statements (e.g. “people like it” as a criteria, “more maintainable”, etc.), but the last paragraph is on the spot IMHO.
For a new language like Kotlin, it is not that important whether it is “better” or “worse” than Java. What is important is whether devs would prefer to use it and be able to convince their management to let them do it.
However, Android is not a good indication of devs willingness (more on that in the next article). The real challenge for JetBrains is to win over backend developers, and create a popular web frontend Kotlin framework. It is too early to predict either success or failure in this area though.
I don’t think Kotlin increasing developer productivity, and JetBrains using Kotlin as a means to drive business, are mutually exclusive. In fact, I think they go hand in hand very closely.
In order for Kotlin to succeed and be a leading programming language that drives business for Intellij, they need a way to market it to developers and give them a reason to choose it over a competitor.
Did they make it “just because it’s better than Java”? Not for that sole purpose, but I absolutely believe they made Kotlin to be a better and more productive language than Java. I also believe that was a driving factor for them, because that is what the community needs, and therefore what the market needs and what drives their business forward.
That makes sense and thanks for reminding me of Strategy Letter V
On the other hand, there is the question of the ultimate (lucrative) édition versus the free community edition.
Jetbrains has gently built a better alternative (Kotlin js / multiplatform ; spring boot functional DSL style) where I only need the community edition
It can probably argued that it’s also a sound long term strategy but thanks anyway 🙂
What you say is not implausible, but it includes reading a bit too much into the situation.
JerBrains, if it’s a good company (which seems to be the case), has many good engineers. Good companies know that they need to give their engineers enough time and space to work on other/side projects to keep themselves motivated and engaged.
It could be just as likely that some engineers were bored or fed up with Java and wanted a better language, so they went about designing one.
Jonathan Blow for example is developing a programming language for similar reasons. He’s running a company so ostensibly he cares about profits, but he also mentioned several times that he’s not after “maximum” profits; he wants to gain fulfillment. https://www.youtube.com/watch?v=TH9VCN6UkyQ
Hasen, thanks for your comment.
I think your perspective is an important addition to this post. I’m pretty much sure that this is exactly how Kotlin started – several brilliant engineers brainstorming and hacking some concepts together.
This is called bottom-up innovation and it is very widespread in good companies that empower their employees and don’t just treat them as code monkeys.
Said that, by the time Kotlin went open source, the business motivations described in this article probably replaced the engineering ones. It is also a very common aspect of bottom-up innovation.
Thank you for bringing up this important point.
Probably, they were also looking at the budding Android market, the uncertainty following the recent takeover of Sun by Oracle, and the glacial Java improvement process. And, still no lambdas in Java 7, which came out around the same time.
By releasing their own language, they could stay ahead of the curve of Java development (not that difficult), and be an attractive partner to parties that have an interest in moving the Java platform –which is not necessarily the Java language– forward, and either don’t have the patience to wait for Oracle, or don’t want to be dependent on them.
Probably, I’m pre-empting your next article now. Also, I’m speculating.
On the other hand, for some reason, Oracle appears to be moving towards a six months release cycle. Maybe they got the message that things were moving too slowly, and they are no longer the only player. Again, speculation.
This, though, ups the ante for JetBrains. And that’s a good thing, because it leads to competition. If Kotlin is indeed better than Java, than Oracle have some catching up to do, in order not to become irrelevant. If Java is better than Kotlin, JetBrain’s future is negatively affected.
Aside from the fact, which you’ve already pointed out, that “better” is a highly subjective term, and depends on the point of view you’re taking (development, business continuity, etc).
Oracle can sink a serious amount of money into Java if they want, much more than JetBrains can into Kotlin, but on the other hand, nothing is stopping some other company, with a huge amount of money in the bank, to have some sort of strategic partnership with JetBrains.
In the end, it’ll be the market that decides which is the better language: the one that survives in the end.
I couldn’t agree more with your last statement – only time will tell whether Kotlin is a real game changer, or just another overhyped “Java killer”, many of which raised and fallen in the past 20 years or so.
However, these languages are not exactly equally probable winners – Kotlin has much more to prove, and the numbers, as they currently stand, are not in its favor.
That’s indeed very interesting. Though I myself is quite skeptical about cross-platform development prospects.
I was intrigued by the two first parts of this series. Is the third one coming? If I remember correctly, it was supposed to be about the reason Google is promoting Kotlin. Thank you.
First of all – thanks for holding me accountable for my statements. It really gives motivation to know that people are interested.
Third part is definitely coming and it will indeed be about Google’s adoption of Kotlin for Android. I already completed all the research.
This is going to be the most difficult article I wrote to day, and, as such, it is not something I can do “on the fly”. Unfortunately, I couldn’t allocate the required amount of time until now.
In any way, I need to complete it before Google IO 18, because afterwards there will probably be other news to blog about.
Thanks again for your interest and support.
If they wanted productivity they would have just used groovy