Kotlin 2026: Layoffs, AI, Google — Is the Golden Age Over? Jake Wharton Explains
In a Nutshell
Kotlin succeeded by offering incremental migration from Java with complete tooling support, but its career advantage has evaporated as adoption became ubiquitous. Jake Wharton left Google to build products rather than tools, joined Skylight after rejecting 95% of opportunities that violated his values against AI, crypto, VC funding, and poor work-life balance. He argues AI will collapse under rising costs and training data degradation, while Kotlin's ecosystem and tooling advantages outweigh Swift's superior language design, though Kotlin should avoid single-platform targets where native languages excel.
These notes were generated by AI and may contain inaccuracies.
The LLM industry operates on a standard VC playbook: subsidize usage, addict users, then switch to value extraction. Coinbase CEO eliminated 14% of staff while citing AI. Cash App eliminated 70% of engineers after Jake Wharton's departure.
In 2010, Java was the number one programming language globally, and Android ran on Java. Kotlin emerged when the Java language had become stagnant under Oracle's stewardship. Release cycles occurred every two years, leaving the Google Android team limited by what Java provided. The community was exploring alternatives like Scala and Groovy when Kotlin arrived at a moment when developers sought more modern language features.
Kotlin succeeded because JetBrains was a tooling company that could deliver a complete language with IDE support and infrastructure. The language leveraged the existing Java ecosystem, allowing developers to gradually introduce it without discarding Java libraries or entire codebases. This incremental migration capability made adoption significantly easier than languages requiring complete ecosystem rebuilding.
Jake Wharton spent five to six years at Square, where Kotlin was adopted three years prior. He wrote a public document justifying Kotlin adoption that became a general argument for the language, generating significant Android community interest. When Google recognized Kotlin's potential benefits, they approached Wharton about joining the Kotlin team, offering the opportunity to make Kotlin the first-party official Android language.
The Android team showed hesitancy about transitioning from a 10-12 year Java foundation with deep stack integrations to a relatively new language. Kotlin had only stabilized a year or two prior. Google introduced Kotlin thoughtfully through incremental adoption rather than a hard switch. Sibling Kotlin libraries were built for published libraries long before any Java-based ones were rewritten in Kotlin.
Initial years saw a false association that Kotlin was exclusively for Android, with some articles claiming it was built by Google for Android. Backend services that would have been written in Java now use Kotlin, with Spring making many offerings Kotlin-first. JetBrains pushes the multiplatform story, enabling use on iOS and desktop applications, including the JetBrains toolbox itself.
At Square, backend services started in Java but Kotlin excitement from Android developers spread to Java backend teams, eventually gaining approval for broader use. Android adoption served as a catalyst for other ecosystems.
Kotlin represents what Java wants to be in approximately ten years. Java cannot break existing code, making language evolution slow. All features eventually coming to Java already exist in Kotlin today. Kotlin honors Java legacy by targeting older JVM versions like Java 8 and Java 11 while providing modern features.
Facebook, Google, and Amazon use Kotlin in production, both on mobile and backend services. Facebook recently contributed their Kotlin formatter to the Kotlin Foundation to become the first-party Kotlin formatter. These represent some of the world's largest codebases transitioning to Kotlin.
Wharton planned to spend approximately two years at Google making Kotlin the first-party Android language, then return to using the tools he built. When two years arrived, Google approved another desired project, extending his stay by nine months. Ultimately, he wanted to build things with tools and libraries rather than only build tools and libraries.
Google is a very large company. Android operates relatively isolated from other Google products. Wharton has issues with Google's practice of locking users into their products and services, though the Android team itself was fantastic.
Finding a new job in November 2025 during massive tech layoffs was not easy. Wharton was selective with requirements and left voluntarily without urgency. Jobs exist but the market differs significantly from five years ago when anyone could get hired as an Android developer with high compensation. The market bottom has not completely fallen out, but differentiation and more effort are required.
Senior Kotlin engineers in the US generally see $200,000 and up, offset with equity around $100,000 per year spread over four years. Companies are more mindful about compensation than previously. Higher compensation requires going to high-risk, high-reward opportunities where equity could go to zero or 10x. Wharton prefers consistent cash-based salary over equity bets at his current life stage.
Kotlin is no longer a career advantage due to its success and ubiquity. Google making it the first-party Android language transformed it from differentiator to expectation. Similarly, Compose UI shifted from rare to default requirement. The only remaining differentiator would be deeper language features like multiplatform capabilities.
AI: Rejects AI companies, AI-based products, or forced AI usage for development. Software quality has not improved over recent years, and LLMs are not contributing to quality. The technology is built on the largest copyright infringement in history, ignoring artist copyright and code licenses. Training data practices mirror Facebook's BitTorrent downloading of millions of books. The technology represents a land grab where CEOs dictate day-to-day engineering decisions rather than engineers choosing tools.
No crypto: Cryptography is acceptable, but cryptocurrencies represent a Ponzi scheme with no real value. The system has become predatory, with only those profiting from others' suffering or building businesses on top making money.
Remote work: Works remotely since 2015 but happy to visit offices a couple times yearly. Values in-person interaction and human empathy but cannot return to daily commuting. Flexibility is essential with children.
Open source: Default practice is putting work in the open. Companies are built on others' open source work, and contributing represents paying forward the reciprocity that enabled starting with Linux, Android, SQLite, and the JVM.
Customers over shareholders: Seeks companies with sustainable business models that won't extract value from users to pay venture capital or satisfy Wall Street investors. Many VC-funded products create dread with updates due to broken functionality or paywalled features.
People over profits: Avoids companies using VC funding to undercut markets through exploitative practices like Uber and Airbnb, which become more expensive once subsidies end. The gig economy makes workers think they can earn extra money while the companies extract value.
Jake Wharton discusses how gig worker economies like Uber fail to account for depreciation of vehicles, gas mileage, and other costs. Workers lose rights and protections compared to traditional taxi drivers, where industry systems exist to protect workers that do not exist in gig worker economies.
Jake prefers working at companies that do one thing well rather than trying to be everything to everyone. His best days at Square were when the company was small, around 200 people, when everyone knew each other and could execute on a vision rapidly. At this scale, there was a purity and ability to focus on executing well on a specific segment.
When Jake left Square, the company had grown to 12,000 people. Large companies develop habits of bureaucracy that slow down product development. Engineers start getting desperate to find new things to bring in new users. As companies grow larger, engineers' responsibilities tend to narrow significantly.
Jake recalls hearing about a Twitter engineer who was responsible only for the DM interface for five years. This narrow focus causes engineers to lose flexibility to enjoy different aspects of the product and reduces opportunities for learning. Jake prefers the flexibility to bounce around within a product and work on different things.
Jake emphasizes that depending on where people live, where they were born, and their previous jobs, there are advantages and disadvantages that extend beyond obvious factors like gender or skin color. He gives an example from Cash App where coworkers in different countries doing the same job were paid market rate that was half what US employees received, simply due to geographic region.
Discriminating against people because of things they cannot control is described as a ridiculous concept. Jake believes these values should be so normalized that they shouldn't need to be explicitly stated as company values.
Jake does not have work chat or code review on his phone. During his first five or six years at Square, he had Slack and GitHub on his phone and felt fine reviewing PRs on Saturday nights. However, he realized this sets a precedent that becomes an expectation for others, particularly interns and junior employees who don't understand the context of his personal work-life balancing.
He wants to instill that it's okay to close work email at 5:00 p.m. on Friday and not open it until 9:00 a.m. Monday, making this the norm rather than a weird exception.
Jake's values around avoiding VC funding and seeking profitable companies with healthy business models eliminated approximately 95% of potential companies. The VC-funded model typically involves being built on someone else's technology subject to price fluctuations and geopolitical risks. While healthy VC-funded places exist, they are exceptions rather than the norm, and often aren't building things he's interested in.
After three months of job search, Jake joined Skylight because the company echoed his values and offered a product he was personally interested in as a customer. Skylight makes a wall-mounted or countertop tablet running an Android application for managing families and households, described as a "family operating system."
Key attractions included the hardware product focus, the ability to do hardware tinkering, not being in the Play Store, and working with AOSP (Android Open Source Project) and actual hardware devices. Kevin Barry, author of Nova Launcher, had joined six months earlier, providing additional confidence in the company.
Jake states he did not have to compromise any of his nine values to join Skylight. While the company hadn't done real open source work previously, they were open to it and understood his ongoing open source maintenance responsibilities. They have LLM functionality but it's tastefully added, entirely optional, and not the core of the product.
Skylight builds a product focused on families, centered around managing households and getting things out of parents' brains. Features include tracking kids' activities like soccer or recitals, shopping lists, meal planning, chore accountability, and teaching healthy habits. The goal is cognitively unburdening family heads so they can focus on being good family members.
In May 2026, Coinbase CEO Brian Armstrong cut 14% of staff, claiming non-technical teams are now shipping production code using AI. Jake notes that Coinbase fails all of his values and finds Armstrong's statements shortsighted. He points out that the LLM industry is propped up on VC money, with GitHub Copilot recently transitioning from monthly pricing to usage-based pricing.
Jake predicts that as AI costs rise by potentially an order of magnitude or two, companies addicted to AI will face unsustainable expenses. He notes that in some cases, AI costs are already exceeding the salary of engineers they were meant to replace. While he supports lowering barriers to entry for contributing to codebases, he distinguishes between responsible use (augmenting existing capabilities) and irresponsible use (writing code beyond one's capability).
Jake takes an extremist stance against AI agents for coding, choosing never to use them. He argues that relying on these systems transfers power away from workers, making them replaceable cogs. He notes that in the US, workers may have their accounts turned off before even finding out about layoffs, contrasting with Germany's worker protections.
If AI writes better code than him in six months, Jake plans to keep working at smaller companies making less money while retaining his happiness. He notes he's fortunate in his career position to take this hardline stance. He believes LLMs will eventually collapse when fed their own output data for training, citing studies suggesting this is a certainty.
Regarding the argument that AI has killed Kotlin's main advantage over Java as a boilerplate killer, Jake notes that code is read 10 times more than it's written. He argues that the thinking part—deciding the right way to solve problems, drawing boundaries, and modeling complex business logic—is more important than the initial writing. The maintenance of code over time, handling bugs, requirement changes, and business evolution is where languages truly shine.
Jake acknowledges that Java hasn't sat on their laurels and has made significant progress with records, sealed classes, moving to a six-month release window, and focusing on experimental language features that can be tested by the community.
Since moving to a six-month release window and focusing on experimental language features that can be tested by the community, along with infrastructure work behind the scenes to allow easier language revision, many language features introduced are more thoughtfully designed than Kotlin. Kotlin had to shim features into Java bytecode compatibility, with Kotlin hitting the scene when Java 1.6 was the bytecode version it compiled to. Language features had to be turned into compatible Java 1.6 bytecode.
Java doesn't face this constraint. They can introduce things like records and new bytecodes, modify the virtual machine to suit language needs, with everything evolving in tandem to build cohesive execution. In contrast, data classes can only emit regular Java classes with regular methods and maybe some metadata.
Kotlin does better than Java with its nullability story. Not modeling null in the type system creates the billion-dollar mistake of null pointer exceptions. The issue isn't that nulls exist—you always need the concept of absence—but that they're not modeled properly in the type system, forcing reconciliation with optional values. When everything is optional, there's opportunity to ignore it and get failures at runtime.
Kotlin models null by elevating the concept of absence into the type system, eliminating an entire class of bugs from programs. The simple change of adding a question mark at the end of a type when something is optional remains a powerful concept.
Swift had a clean slate where they could decide language features and capabilities, plus decide how it would be compiled without targeting an existing representation. Error handling in Swift is more first-class in the language, forcing handling of functions that potentially throw. This is forced upon developers similarly to how nullability is forced in Kotlin.
Kotlin's exception handling doesn't model failure modes—you don't know the failure modes of functions you're calling. The JVM has its exception concept with Java's checked and unchecked exceptions, but Kotlin made everything unchecked. This is an ongoing pain point in Kotlin language evolution—how to model potential failures so every function call forces reconciliation with possible failure, rather than leaving landmines in codebases.
Swift marks throwing functions and requires either putting the bang at the call site or doing a safe version of calling. Because Swift targets native code, it has proper structs with dense memory representation. Kotlin built on the JVM where everything is a class with fields, creating pointer indirections in the VM. Memory representation spreads objects over the heap with constant pointer dereferences, versus packed dense data structures that fit in CPU cache lines.
Swift is a better designed language than Kotlin with not too many things Kotlin has over Swift. Kotlin's benefits are secondary—it's the ecosystem around it, the library ecosystem, the open source ecosystem. Tooling in Kotlin with IntelliJ and build systems are miles better than refactoring in large iOS codebases. Xcode got rename refactoring after years when IntelliJ had it 20 years ago.
Specifically the language itself doesn't have too many things heads and tails above Swift. Everything around the language makes it an enjoyable experience. If you design the best language but have no story for tooling, libraries, static analysis—all things needed to productionize a language—then adoption won't happen even if it's the best language in the world.
Rust does the best job in error handling. Design decisions feel intuitive—representing things in the type system, thinking about ownership and borrowing, who's responsible for closing file descriptors. These concepts come from pain of not having them in languages—leaking memory, leaking file descriptors, null pointer exceptions, unchecked exceptions thrown from unexpected functions.
Rust is a hard language with a hump to get over before it becomes intuitive. The concepts align with thinking even if not the best execution in terms of learning difficulty. The way Rust models and represents failure handling is considered the best approach.
For hobby projects, different languages are preferred over Kotlin used in day jobs. Microcontroller work with very low memory is outside Kotlin's comfort zone—the language wants more of a full operating system around it. Kotlin is too big to fit in embedded, real low-level spaces.
Kotlin isn't the first choice for web applications. If there's an existing codebase with Kotlin and the desire to reuse it without reimplementation, or seeking a single source of truth for business logic, Kotlin's web compilation capability is advantageous. But starting fresh to build web applications, Kotlin wouldn't be the first choice. Compose UI on the web doesn't really respect how the web works.
When targeting only web as a platform, Compose UI or Kotlin wouldn't be chosen first. The ability to flip a switch and take existing code to different places is beneficial, including iOS. The idea wasn't to replace iOS engineers but to free them up for interesting platform-specific work like user interface, dynamism, animation, and interaction.
For iOS-only applications, Swift would be the safe bet rather than Kotlin. Kotlin can work everywhere if choosing to target multiple platforms, but when targeting single platforms from scratch—embedded, web, iOS—honoring what makes each platform unique means Kotlin isn't the first choice.
For embedded programming as a hobby, Rust is chosen. Rust has a cool embedded story with libraries exposing interesting hardware problems in interesting ways. The async concept maps to hardware so button presses can be awaited rather than polling or setting up interrupt mechanisms. Since Rust isn't used in day-to-day work and the language concepts speak strongly, it's chosen both to accomplish goals and as an excuse to explore the language.
The primary work over five years was building a multiplatform solution for business logic. The problem was needing to update apps faster than through app stores, usually around legal requirements like state regulations requiring wording changes within three days or facing prevention from sending money in that state.
The solution enabled updating parts of business logic and user interface without requiring app store updates. After evaluating technologies, Kotlin Multiplatform was settled on, targeting JavaScript as the primary engine. Android and iOS apps shipped a JavaScript engine. Compose was used but not Compose UI—all logic was written in Compose running in the JavaScript engine, reaching into the native application to marionette the user interface.
Requirements could be shipped as downloadable client updates, with new logic running on app restart. Views remained native and felt intrinsic to the platform, with users unaware of background changes. There was indirection between UI and business logic that could be updated out of band.
JavaScript was focused on because that's what existed at the time, with plans to switch to WebAssembly as the ecosystem matured. From a technological perspective there were limitations but it was functional. Problems encountered were often people problems—getting buy-in from different product parts, management churn. The project was successful in execution, shipping and holding loadbearing screens that millions of people interacted with daily.
As the company changed, they wanted a different approach and the project was wound down. Because nothing was product-specific, everything is open source—the libraries built, the tools, with even spin-off libraries. The experience was rewarding, taking developers out of normal Kotlin comfort zones into the JavaScript ecosystem using Compose without Compose UI. Technology choices, libraries, and open-sourced stuff heavily influence current work.
Kotlin Multiplatform is unique in how it targets platforms. On JVM and Android, it compiles to Java bytecode. On native (iOS, PC, microcontrollers), it uses LLVM to compile to proper native code. On web, it compiles to JavaScript and now WebAssembly. It lives in each ecosystem using native execution methods.
Flutter compiles to native code but has its own entire rendering stack like a game—it has its own UI toolkit looking the same regardless of platform. This doesn't honor what makes platforms unique by removing intrinsic UI toolkit elements and recreating the entire rendering stack.
Kotlin allows talking to the same objects in the same memory space on iOS, linking directly against libraries, all compiled together in a single binary. On web, JavaScript APIs can be exposed, all compiled into a single bundle with the same performance characteristics. You're not running something like a foreign body on each platform.
With Kotlin Multiplatform, you can pick and choose how much to share—you don't have to share everything. You can share just annoying-to-write-three-times or error-prone pieces, then do native work on each platform for best user experience. Apps feel like any other app on web or iOS, with shared code not obvious to users.
React Native is liked more than Flutter. Flutter's decisions are considered offensive. Google controls both Android (most popular OS) and Chrome/web (most popular platform) yet built a third platform due to company dysfunctions. Apple would never build a competitor to Safari and iOS.
React Native tries hard to render using native UI of each platform—React business logic on web gets DOM elements, on iOS gets UI views, on Android gets Android views. This honors platforms by trying to give native feeling experiences. Good React Native apps can absolutely fool people because they're using normal UI toolkits—you can't tell they're powered by JavaScript.
Flutter apps can be identified even if average users couldn't tell. The Cash App solution wasn't far from React Native—they looked at it, liked many things, thought some decisions were wrong. React Native gives tons of UI control on each platform with properties to tune rendering.
The design system was already in place across codebases, so rendering from shared codebases was restricted—you'd just say "this is a primary button" without setting colors, corner radii, click behavior, or Android ripples. React Native allows setting corner radii and similar properties, giving more power.
Competition exists in the Android ecosystem as competitors, but React Native apps would be preferred over Flutter apps.
Native UI is still considered the best UI. Product people want apps looking the same on every platform for brand consistency, but most people aren't jumping between platforms—they're on one platform using 20 apps and jumping between apps within that platform. Consistency within platforms gives comfort. When buttons or list
When a button or list dragging behaves the same way across apps, it gives users comfort and intuition about expected behavior. The goal was to maintain native UI on each platform so things can look different, but share the business logic behind it. On Android a toggle switch might be horizontal while on iOS it might be vertical. The details of rendering on each platform are not important to the shared business logic that nobody wants to reimplement three times. The aim is to eliminate situations where iOS and Android counterparts handle the same case differently, freeing people to make the native UI experience the best it could be.
This approach is very different from React Native where you can simply put pixels on the screen. Redwood requires an existing design system concept with reusable components, sections that appear on multiple screens, high-level concepts, and modeling of how reusable code is exposed. It is not turnkey and requires significant upfront investment in building those foundational elements. This is not necessarily a path to pick when building something new because of the extensive work needed to get even the first button on screen.
Redwood is designed as a library that slots in rather than the foundation on which everything is built. This approach acknowledges that things change—apps can be 10-15 years old and have gone through different reactivity models, languages, and UI toolkits. Building as a library shifts burden onto the consumer since it is not a one-liner drop-in or base class extension pattern. The flexibility allows slotting in and out as tastes and product needs change over time. If built as a framework deeply tied into everything, evolving to something else becomes a huge undertaking.
With Redwood, the JavaScript part where dynamic updating occurs was built as a completely separate component. Redwood could run by itself completely natively and get the design system abstraction, then use Kotlin Multiplatform to compile business logic natively. The underlying updatable mechanism called Zipline was separate and could be slotted in underneath since it knew nothing about Redwood and Redwood knew nothing about Zipline, though glue code was required to combine the bricks into higher value.
The current setup is vanilla IntelliJ or Android Studio depending on the work. Plugin usage is minimal, with only a SQLDelight plugin for SQL work. A separate terminal application called Ghostty is used outside the IDE, despite the new terminal in the IDE being very good. Firefox remains open with documentation, with alt-tabbing occurring between these three tools throughout the day.
The preference for Firefox over Chrome stems from recognizing that browser market competition created Chrome, but Chrome has now become the villain with disproportionate market share, allowing it to strongarm the ecosystem rather than participate in a healthy way.
A subreddit exists with CSS changed so every comment displays Jake Wharton's name. When someone at Google unfamiliar with this would see a screenshot of an incendiary comment supposedly from Wharton about Flutter or Google products, they would report it to his manager. Wharton had previously explained to his manager's manager how Reddit allows CSS modification of comments.
The historical answer was that public by default is disliked, preferring internal by default as in Java, particularly from the perspective of someone working in libraries where careful consideration of public API exposure is necessary. The current answer centers on exception and error handling not being a thoughtful choice but rather a necessary one due to Java and JVM bytecode interop requirements.
Exception handling behavior can mean the difference between an unresponsive application where no buttons work because an invariant threw an exception on a background thread and crashed. Mobile apps historically built assuming Wi-Fi 20 feet away and fiber internet create situations where intermittent cell connectivity on a train causes the whole app to grind to a halt or fail and become unusable. The language should model fallibility of things in a way that forces developers to think about errors, especially when the code calling a network request might fail at the call site without knowledge that underneath it is calling a database or remote service.
Gradle is a point of contention despite providing great value. Android existed before Gradle, making the build system extremely welcome when it arrived. The early focus on making build scripts easy to write with cute syntax rather than correctness or performance created ongoing pain. The team had to back their way into correctness and performance over 10 years, meaning syntax that was written often proved to be the inefficient syntax, requiring incremental rewrites of build files to achieve fast, incremental, correct, reliable, performant builds.
Android and mobile were constantly evolving and growing during the first half of the two decades, creating opportunity to learn and try new things with excitement for new platform capabilities at each I/O. In recent years, the feeling has shifted to dread about what product updates might take away. Hardware projects provide an avenue for engagement, allowing code to be written and deployed to a phone for fast, real interaction with physical, tactile devices that interact with the world beyond a 6-inch screen of pixels.
Learning different languages like Swift, Rust, Zig, C, or Haskell opens the mind to different ways of doing things without needing to become proficient. The goal is to bring those experiences back to the primary language. Haskell particularly teaches different modeling approaches. Learning other languages is recommended as general advice for growing as a developer, similar to how universities require history, math, and science classes to round out engineers.
Coupling language learning to something personally relevant provides intrinsic motivation. A concrete example involves replacing a disliked sprinkler system controller that is simply a microcontroller and 20 relays, providing an excuse to learn microcontroller programming and get back into basic circuit design with relays on a board alongside a Raspberry Pi.
Kotlin still holds interest after the K2 hump, with the libraries and language team picking up pace on additions to the language. Programming remains a source of delight with much left to learn outside day-to-day work. Some developers prefer wholly unrelated activities when not working to prevent burnout, which is fully supported.
Learning more than one programming language is definitely useful, though not necessarily five or six. Being entrenched in a single language limits exposure to different choices language designers have made and why. The times when concepts from other languages suddenly apply to current problems are notable. Rust's ownership concepts can be brought back to Kotlin and Java, helping identify situations where implicit contracts around resource ownership could create memory leaks or prematurely closed connections when refactored by others.
Learning C, Zig, Rust, or Swift exposes developers to packed data structures utilizing every bit that fit multiple items in a cache line, explaining performance differences compared to chasing pointers and experiencing cache misses in other languages.
A dream project involves bringing ownership semantics to Kotlin. At KotlinConf, a researcher presented early notes on what ownership semantics might look like in the language. Java's pattern of defensive copying lists because all lists are mutable would be eliminated by ownership. Kotlin's mutable and readonly list split helps but does not fully address the problem where giving a list means the giver cannot touch it anymore or allows borrowing with continued mutation ability.
Kotlin benefits from leveraging the Java open source ecosystem and vice versa. When OKIO and OkHttp were rewritten in Kotlin, strict binary compatibility was maintained so code would still compile, link, and work at runtime despite the additional Kotlin standard library dependency. Some purists took issue with this. The language culture supports openness with the entire process visible and changes observable over time, contrasting with Swift's initial approach of presenting finished features once a year from Apple developers.
Kotlin's open source ecosystem is notably larger than what exists in Objective-C or Swift. As soon as Kotlin became available on Android, there was a massive outpouring of open source libraries written in Kotlin. When Kotlin became a capable multiplatform target, developers created extensive multiplatform libraries to fulfill basic needs for writing multiplatform code.
This culture stems from JetBrains' approach to language management and the early days of the language, where the people who were there first set the implicit rules that everyone lives by. When a community starts with a culture of putting things in the open, that cycle perpetuates itself. In contrast, if a community culture develops where the language is only used in serious business contexts where companies are very protective about their interests and IP, nothing gets open sourced, and that becomes reflected in the community.
Kotlin was used in worlds that already had extensive open source practices, and JetBrains decided to do everything in the open, which reinforced this culture.
Open source dependencies present both advantages and disadvantages. There is significant value in building on top of other people's work, but there is also potential for loss since you become tied to that library depending on how you integrate it. When library maintainers make decisions that don't align with how you think the library should go, it can feel like a betrayal. Libraries can also have "rug pull" moments where they switch licenses to try to make the project sustainable, which can be problematic for users who had been getting it for free.
The core problem stems from a misperception of what it actually means to use an open source library. Users need to feel responsible for the dependency and treat that code the same as code they write day-to-day, because ultimately all of that code gets bundled and shipped to end users who don't care about what libraries are used.
There's a problematic notion that developers need to get permission to contribute to open source libraries at work. This is the wrong concept because if you didn't use the open source library, you would write the code that does the same thing and be responsible for it. If you want to change an open source library that ships in your app, you should just contribute to it. It should be the norm that because it's your dependency, you feel ownership over it and pay attention to what goes on in the same way you pay attention to your own codebase.
The mechanism of distribution can make this challenging because you put one line in your build file and suddenly all these things get pulled down automatically, making them feel very far away. When you get burned by a dependency, it's often seen as the open source project's fault for not understanding your needs. In reality, if you took on more responsibility for participating, maintaining, keeping an eye on the project, and ensuring it's going in the direction you want, you would see changes coming and could plan for them.
Even if LLMs can write uninteresting, repetitive foundational parts of codebases, this undersells the value of having a single codebase where someone fixes weird bugs that you may never hit currently, but might encounter after a refactor two years later. The same applies to performance improvements - if someone makes something 15% faster, that improvement benefits all users. The distribution of contribution across different codebases provides ongoing value that goes beyond what individual developers would implement themselves.
Companies invest in open source for several reasons that can be hard to quantify on a spreadsheet. Beyond getting improvements for free from community contributions, open source work contributes to the perception of engineering culture. People can look at the open source code coming out of a company and assess its quality, which can lead to recruitment leads. Companies like Google and Facebook historically got significant leads because people could see the cool things being built there.
Another benefit is that it feels good as an engineer to be able to show people what you're working on rather than just telling them. Being able to point to GitHub repositories allows others to figure out how to use the technology and potentially do something else with it. However, this shouldn't be forced - requiring companies to open source things just to look good as an engineering organization will appear disingenuous.
Not everyone wants to participate in open source. Some developers don't want to be seen publicly or have a GitHub presence because of the responsibility and burden of dealing with issues like users complaining that changes broke their apps, receiving LLM-generated PRs, or managing people who want to take the library in different directions. Having these conversations can be difficult due to human-to-human communication challenges and language barriers when opening yourself to the world rather than just people in your immediate vicinity.
However, there's a certain class of people for whom this is enjoyable and motivating. Selfishly, when you leave a company, if you've open sourced things, you get to use that work at your next company rather than leaving it behind.
Modern open source work falls into several categories. A lot of open source work is implicitly company-sponsored because companies employ people who work on projects full-time during work hours. This is how many libraries on company organizations came to be.
Problematic cases arise with personal projects that become load-bearing in someone else's codebase. When you put something in the open as a side project, it comes with a standard Apache license that explicitly states there's no contract or guarantee about the code. When personal repositories become unmaintained after someone leaves a company, there's no good model for getting them back to a healthy state where companies relying on them contribute back, whether monetarily or through time and engineering effort.
Contributing to open source can take forms beyond monetary payment - filing issues requesting features versus actually building features or helping with bug fixes and issue triaging represents different levels of contribution. The goal of finding ways to get people paid for open source remains important, as many projects used by massive companies are built primarily by one person who may not be getting sustainable compensation.
Languages need to outlive their original creators, and it's acceptable for people to stop working on something and move on to other projects. After building something successful over 10 years, wanting to work on something else is reasonable. The Kotlin community was fortunate that the language survived Andrey Breslav leaving JetBrains in 2020, which was very much a non-incident and a testament to how everything was set up around the language.
This represents a healthy development for languages. Almost every big successful language nowadays operates without a benevolent dictator model, instead using shared organizational structures that manage the language in tandem with the community.
Zig represents a different example with its acting benevolent dictator in Andrew Kelley, but the language is still very young. There's massive benefit to having someone who can make breaking changes like introducing new IO concepts that require rewriting 100% of code if it's what the language needs. However, as Zig reaches 1.0, there should be more shared responsibility through the foundation that owns the language to unburden the primary maintainer and provide stability for the future.
Exhaustive when clauses became a default requirement in Kotlin, meaning all potential cases must be included. This was implemented after Square built a compiler plugin and tool to force exhaustive when clauses. Roman Elizar was involved during the transition from Andrey Breslav at Google, and this feature aligned with the desire to have the compiler identify all places where new cases aren't handled correctly.
While nothing has been directly attributed to individual contributors, the ongoing decisions about what goes into Kotlin align with values about what a programming language should and shouldn't do for programmers. An error and exception proposal that's now over a year old was recently refreshed, and community feedback on such proposals is encouraged.
Since most codebases are closed source, the ways developers use Kotlin and the design patterns they create often suggest language tweaks that could make things easier. If developers don't participate in telling the language what it should be, they're essentially letting go of the reins and letting others control its direction.
Kotlin should be steered by JetBrains, Google, and the community together. This was part of the point of moving the language away from JetBrains into the Kotlin Foundation, creating a structure where no single party controls the language. While the community doesn't have explicit membership in the foundation, community members outnumber people at JetBrains and Google.
Effective governance requires listening to what's happening in the community while wrangling the absolutely insane level of feedback into something digestible to move the language forward. This structure was born partly from Google's experience adopting a language owned by another company, which led to massive lawsuits, making it important that Kotlin couldn't be owned by a company that could potentially harm Google's interests.
If Kotlin disappeared, it would be a significant loss, but programming languages don't need to live forever. Kotlin shouldn't end anytime soon, but it's okay for languages not to grow to infinity or encapsulate every potential use case. Different programming languages exist for different reasons, and if programming fundamentally changes such that Kotlin no longer fits, that could be acceptable.
Personally, losing Kotlin would mean losing the ability to have a job anywhere, as the investment in Kotlin-specific skills means putting all eggs in one basket. This represents a conscious choice to tie efforts to Kotlin and make it the primary professional focus.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
