JetBrains VP, Hadi Hariri shares the inside story of how Kotlin became the de facto programming language for Android and how the company built a developer community around it.
Kotlin has exploded in popularity over the past few years and has become Google's preferred language for creating Android apps, but that wasn't the original plan. On this episode of Dynamic Developer, we talked with Hadi Hariri, VP of Developer Advocacy at JetBrains, about how a company, best known for IDEs, created a programming language and built a thriving community around it. This article is a transcript of our conversation edited for readability.
Bill Detwiler: Let's talk about JetBrains' experience with Kotlin and building the community around it. Tell me how that came about. Tell me about the process for getting it started. Start at the beginning.
Hadi Hariri: Sure. I think that when we started Kotlin, we basically had a community established around JetBrains. JetBrains this year was actually 20 years old. We started Kotlin back in 2010, so we already had 10 years of head start in terms of building a community around our brand and some of our products.
So from one side, I would say, it's not like we started on a clean state. But from the flip side of it, in a sense we did, because we were a company that was essentially building developer tools, IDEs. While the majority of us, most of us at JetBrains, and I'd say that a lot of people in the community would accept that a language is also a tool, there seems to be some difference between a language and an IDE for many.
When we came out with the announcement that, "Oh, we're now creating a language," everyone's like, "No. Just stick to IDEs. JetBrains shouldn't be doing languages." We're like, "Okay." So it was quite challenging. It was quite challenging.
I think that it took many, many years, I would say, to start to ... Well not many, many years. It took a good number of years for people to start looking at the language and building a community around it. There were certain milestones that we hit that made this suddenly shoot really high and really fast. But at the beginning, it was very, very challenging, I think.
Bill Detwiler: What do you think that resistance was in the community that had already existed around JetBrains' tools? Why do you think they were hesitant?
Hadi Hariri: I don't think it really is about JetBrains as a company itself. I think that people start to identify certain brands for certain things. It's kind of like Google is a search engine and they sell ads. Tomorrow, if they come up with a car, you're like ... Okay, well, Google is different. They can come up with a car, or buy a company that does a car.
But if Nike tomorrow comes up and says, "Well, I'm making umbrellas," people will be like, "Why [are] you making umbrellas?" I think that while, again, a language is a developer tool, there was a lot of this mindset of like, "Well, you just do IDEs. You're doing IDEs and tools for other languages. Why do you want to create your own language?" Then of course the additional thing is just like, "Well, you're not just creating another version control. You're creating a language."
I think that there is this psychological barrier between what a language is and every other tool. With a language, people, you really need to convince them, and they really need to see the value in order to adopt it. Because it's a lot of investment. It's a lot of risk. Like I'm going to take my ...
Like tomorrow, if you take a company that that is writing, for example, Java code, and someone uses IntelliJ IDEA, which is our tool, and someone uses Eclipse; tomorrow, if that person leaves, and they choose, they could just use the other IDE. It's not fundamental to the project's success or failure.
Whereas with a language it is. Right? With a language, there is more commitment. You need to make sure that the people coming on board know the language, the people leaving don't leave you in the cold. So it's much harder to just adopt a language than it is just a tool. Right? Even though we feel it's essentially the same thing. So I think that psychological barrier also pushes people back against this, if that makes sense.
Kotlin wasn't created specifically for Android
Bill Detwiler: That's a great segue, I think, to something that I wanted to get to, which are lessons that you learned in the process of developing Kotlin, which really has become the preferred language for developing on the Android platform, right? What are the lessons that JetBrains learned in the process of overcoming that resistance, developing that language, and building the community, saying, "Oh well, they're not just a maker of IDEs. They've got this language, and yeah, I'm pretty happy with it, and yeah, I'm going to adopt it."
Hadi Hariri: I think that first of all, lessons learned. It's difficult, a little bit to answer, because it depends on who and what, because there's so many people involved in Kotlin. I think the one thing that we, not that we would learn, but something that I feel, in a sense, we try to avoid is to be demotivated with the initial reaction.
If you look at the initial reaction, there was some positiveness, and there were a few people in the community that I said, "Oh, this looks interesting. Oh, this looks great. Maybe we should give it an opportunity." But there was also a lot of negativity. There was also a lot of like, "Stick to what you're doing. We don't need another language. This is very similar to existing languages. You're not providing value."
Our persistence in taking the good feedback, building on it, and trying to ignore the negative that was really not constructive, and persisting this, I think, was the biggest lesson that I would say we also learned, and also I think it's important for people to take the negativeness with a pinch of salt. Listen to it, but don't be demotivated. If you have a clear vision, if you have a clear idea where you're going, try and follow that path. Be persistent with that.
One other thing is that not a lot of people really know this, but we never created Kotlin for Android. We created a language that we wanted to use for developing our own IDEs, because we were tired of certain things with the existing languages. We said, "Okay, let's try and do this. It's a good opportunity to also provide other people better experiences."
Then early on, we got some feedback from a few folks saying, "Oh, I've tried it on Android. It doesn't work." And we said, "Well, sorry. Android isn't our focus." But then soon after, we started to see, no, maybe it's not that hard to actually address this, and maybe it might be a good opportunity, which was great. Lesson learned. Listen to the first time. Right? But that's where it started to pick up.
It's that idea of listening to people, and understanding their needs, and trying to put that in the same kind of like, align with the vision that you have moving forward, I think is important.
I have to say, one thing that I feel like has characterized us over the years, and there's definitely lessons that we need to learn here, and there's definitely room for improvement, is that we are kind of open around the stuff that we do, the products that we build, the roadmaps, and try and listen as much as we can to the community.
But it's also, when you are developing in the open, and you get a lot of feedback, you need to balance between the vision and where you want to go and where everyone wants to go. Who was it that famously said ... It was Ford, right? That said about the cars.
Bill Detwiler: Right. He would have given people, if he'd asked people what they wanted, they would've said faster horses.
Hadi Hariri: Yeah.
Be receptive to constructive customer feedback
Bill Detwiler: I think that's a really important point, because it's companies throughout history, big and small, that have to try and deal with that same issue. What was it like for JetBrains? You've got all this feedback coming in. Some of it's negative. Some of it might be constructive. You want to build a community, so you don't want to disenfranchise everyone. How did you strike that balance in JetBrains' case?
Hadi Hariri: I think what we are more or less good at is in terms of reasoning with people. If you look at JetBrains as a company, generally we are ... It started with three people back 20 years ago. When I joined, there was about 150 people. Okay? Now there's about 1,400 people. Yet despite this, it is very flat in hierarchy.
I can never ... I don't ... Generally, the way that it works is that you do not impose your ways at JetBrains. You say, "Okay, I think we should do this. Here's the millions of reasons why I feel this strongly about this." But whatever my position or title is, if someone comes up with good reasoning that we should do it a different way, we do it. We try and reason everything. When we want to add a feature to a product, even within the teams, we try and reason why this is valuable, why we should add it, why we should add it in this way.
So I think that the Kotlin team has been very good at, and especially Andre, who's the team lead for Kotlin, he was always very good and receptive to ideas, and giving people the reasons why this may not work and the way it does. I think that doing this in the open, for instance, like all of the ...
We now have this process in the open, which is called Kotlin Evolution and Enhancement Process, where people actually can file for feature requests on GitHub or on our issue tracker. They come up with a scenario, and then we openly discuss it. We say, "Okay. Well, this scenario may cover this, but it won't cover these things, so maybe it wouldn't be a good idea, because it would open up the floodgates to all of these other issues."
I think that generally seems to work. Being receptive to feedback, but trying to reason with people as to why we should or we shouldn't accept it. I think that that generally is the way we try and balance things.
Bill Detwiler: Do you think that that produces a more invested community? This is something I talk to companies about on a regular basis. It seems to be even more apparent when I talk to software companies and people doing open source development. There's this expectation among developers, engineers, coders, people involved with the development process that there's an acceptance of this give and take. "Hey, look. I'm going to put in a feature request." You're going to look at it. You're going to tell me about it. You're going to do ... There's just more than, say, to use kind of an analogy, a car manufacturer.
There seems to be something in the software community where that comes out more. When companies, when people working on projects can harness that and be transparent, they get a lot of rewards. People tend to approach that and say, "Oh yeah." They appreciate that even if the answer is no, or even if the answer is maybe unpopular, at least you had to prove to people through logic and reason and, like you described, "Hey, here's why we're going to do this, or here's what we're not going to do this."
Hadi Hariri: Yeah. It's funny actually, because just a few days ago, I tweeted, I said that imagine if car manufacturers were to act the way we do as software developers. Someone files an issue for Tesla and says, "I want six wheels. If you don't give me six wheels, I'm going to go buy a Ford." It's like you have to try and say, "Okay. Let's try and reason about why you can't have six wheels, or why we don't have the bandwidth to implement six wheels today."
So yeah, I think there is a tradeoff. But I think ultimately, it works out well. One of the reasons that, one of the things ... Talking about lessons learned. When you have an issue tracker, which is basically where we file for requests for features, for bugs, whatever, that is open, which is our case, it's very, very transparent.
We have, to give you an example, we've got an issue that has been there for 12, 15 years. It's got a lot of votes. One lesson we learned, that even if we don't have the bandwidth, even if we do not even have plans ... If we don't have plans to implement this, we should say it. We just say, "Look. It's not going to happen." People value this transparency, and they value this honesty. They value that you communicate, which is the lessons that we learned. Communicate. Tell them what's going on.
Now, that is also sometimes hard. When you have, like for example, a request that is going on for five years, which shouldn't, but hey, it's life, this is how things work, and there's something going on for a long time ... From your perspective, you're like, "Do I have to really send an update every six months and say, 'Well, we're still not working on this. Well, we're still not working on this.'" Right? So it's a very difficult balance.
Then you get people coming and saying, "Oh, well why are you ignoring us?" and stuff. Now, with social media, it's kind of like crowd bashing, right? "Look. JetBrains has ignored this issue for four years. Let's all go and tell them off."
But I think that the important thing here is, if you're transparent, if you say to people, "Look. This is the plan. We're working on this," or, "We're not working on this," that is the most valuable thing. Some people might like it. Some people might hate it. Some people might say, "Well, if you're not going to work on this, I'm going to use competitor." But you can't make everyone happy all the time as they say.
Building a successful community means being where your customers are
Bill Detwiler: Was there a mistake that you think that you all made early that you learned from, or that you see other companies make? You've talked a lot about lessons. Was there something that you say, "I wish we'd done this," that serves as a warning for other people trying to build a community around either a language, or a set of tools, or a product, or a platform?
Hadi Hariri: I think that the one lesson that we learned is that we need to communicate more with our users around the status of things.
Bill Detwiler: Okay.
Hadi Hariri: Even when we feel that there is nothing to update, an occasional nudge by us saying, "Folks, we're still looking at this. It's still on the pipeline. We're going to get to it as soon as we can," people appreciate that. They don't feel like you're ignoring them. I think that that is important.
I wouldn't ever say that we made a mistake doing feature requests and bugs in the open. I think that that is very, very valuable. It's really given us that DNA of being as transparent as we can with our users, and providing them many communication channels.
I think that this is also a very important lesson for companies. Often, when you look at companies, they look at it from the perspective of what is the most efficient way for us to provide support, as opposed to why don't we enable as many channels as we can for the customers, so that they don't have to make a massive effort to reach us. I think that that's a very important lesson that ...
Bill Detwiler: So it's all about lowering those barriers between ...
Hadi Hariri: Yes, exactly.
Bill Detwiler: ... your customers, the developers and you, and making sure that people feel like, "Hey, look, even if the answer is no, I got an answer."
Hadi Hariri: Yeah. I think that that is important.
Bill Detwiler: Do you think that that's a requirement now to be successful in today's environment? It seems that that's just what people expect, whether it is your car company to some degree or it is software.
Now I would agree with you. I think that there are certain audiences that are much more passionate, and devs fit into that, as someone who has an engineering and learned to code on Fortran and Pascal back in the day, people feel passionate about the things they work on, the languages they've spent time on, the tools they use.
But it seems to remain across a variety of products and companies that we live today. It just seems to be the world that we're in. Do you think that ... That's been your experience, it sounds like, with Kotlin, with the other tools that JetBrains makes?
Hadi Hariri: I think it is critical. I think that definitely, if you want to build a community, you should be where the people are. You should be there for them. You should engage with them. You should interact with them. You should be as transparent as you can with them to try and build that trust, and build a successful product around it. Otherwise, it just doesn't work. Especially in our field.
Sure. You're absolutely correct. We've come to expect this, especially with social media. Nowadays ... But there's two types of companies, right? There's those companies that are actively there on social media, on different channels, trying to help you. Then there's those ones that want to do damage control. When you're being ripped off, or you're being ignored ... Yourself, you've probably seen a million times someone tweeting and saying, "Thank you very much, XO and Y, for ignoring me, blah, blah, blah." Then immediately, they respond to you on social media.
Then there's other companies that ... Back in the old days, I don't know if you remember, we used to have these things, airplanes. They used to fly in the air. Yeah. A developer advocate, I used to fly around a lot. There was two types of airlines. There was one that I could cancel, book, rebook, do everything I could over Twitter with them. Then there was the other one that their Twitter interaction was limited to, "Please fill out this form or call this telephone number."
I'm a fan of the first. At the end of the day, the better their company treats you, the better you advocate for it, the better more word of mouth that company gets. So for us, if you want to build a community, you've got to treat people well. Then that flourishes in a good way.
To give you some numbers, when we started Kotlin, in terms of a community, we used to use the BBS. You remember the BBS?
Bill Detwiler: The old bulletin board services?
Hadi Hariri: With the ASCII ...
Bill Detwiler: Yep, yep, yep.
Hadi Hariri: But we were on IRC. It was like six of us, literally like six of us, two of us from JetBrains and four other people. Never anything went on. Then one day, I said to my colleague, I'm like, "You know what? Maybe we should just try Slack." We created a Slack channel. Then this started to build up. We now have I think around 30,000 people on the Slack channel. And there's like a hundred different channels on there. It's a very welcoming community.
But that also takes time. It takes effort. You need to be there. You need to moderate. I'm there a lot of times. My colleagues are there a lot of times, making sure we have code of conducts in place, making sure if anyone steps out of line, we kind of nudge them and say, "Look, this isn't the expected behavior." It's not only a matter of growing the community, but it's also important to keep that community friendly, a safe place, and a welcoming place, which is just as critical as well.
- Developer doing good: How one coder is helping feed his community during the COVID-19 pandemic (TechRepublic)
- Get TechRepublic's Dynamic Developer podcast (TechRepublic)
- 5 developer interview horror stories (free PDF) (TechRepublic)
- Photos: The 20 most influential programmers of all time (TechRepublic)
- Low-code platforms: An insider's guide (TechRepublic)
- Chaos Engineering: A cheat sheet (TechRepublic)
Programming languages and developer career resources (TechRepublic on Flipboard)