Moderne

Moderne is a pioneer in the field of mass-scale automated code refactoring, and it has some pretty interesting origins. In this episode, co-founder Jonathan Schneider talks about the genesis of Moderne, how he started his open-source journey from being an engineer at Netflix, and their current initiatives, including some interesting developments at Openhaus. Tune in for more details!

---

I am pleased to introduce Jonathan Schneider to the show. Jonathan's actually on his way to London and this is going to be the first time, actually, Jonathan, probably meet with you face to face. Do you want to give us a little bit of background of where you are right now and how come we're talking to each other?

That's right. It's a pleasure to be here, Ben. Right now, I'm in what we jokingly call the Bay area, which is Miami, Florida. It's honestly easiest. It's easier for me to get to London on a direct flight than it is for me to get to San Francisco at this point. The zone and the jet lag is much easier going there. I feel like it's my second home. We're talking because this is an open-source show and I've spent many years in open-source and have dedicated the last several years of my life to a project called OpenRewrite on automated refactoring at scale.

Let's go back to years ago when you were an engineer at Netflix. It's interesting. Probably the most notable thing when I think of Netflix is they seem to stand out as a massive value company with regards to their open source stance and position. Can you tell us a little bit about how you got started at Netflix? Were you working on open-source code that was open from the start? I'm interested to know about the culture that built that up because that's other than their actual product. They stick in my head very strongly around that stance that they had.

Engineering At Netflix

That's right. It is an interesting company because of its industry. If you're going to form a competitor with Netflix, the primary spend will be on content. As I was there, it was $7 billion or something like that they spent on content for that year. They felt like the foundational building blocks of the technology could be, in many cases, open source as a way of attracting top engineering talent to the company and building faster in the open.

The technology itself wasn't the moat to bar additional entrance into that market. I got there when I was working for an insurance company in the middle of Missouri, where I was originally from. One day, I got a recruiting email from an engineering manager there. One of the interesting things about Netflix at that time was that engineering managers did the recruiting themselves. It wasn't a recruiter.

You'd be getting a message from a manager or director directly. I didn't know why he had reached out, but I went and did this interview to work on engineering tools specifically related to the build. I hadn't even been considering moving to California. Within a week, I had gone to California, had an on-site interview, and was packing up my life and moving to California.

It was a rapid interview process. I got there, I got settled, I got working. Some months later, I asked him, “How did you even find me? What caused you to send that initial email?” He said, “You had made contributions to the Groovy compiler, Groovy being a language of the JVM. I said, “Mike, I don't think I did.” He said, “No, you did. That's how we found you.”

I still don't think I did. I may have been involved in some discussion around their parser, but I don't think I had contributed any code to it. It's not that I didn't want to, but open source can feel that way sometimes. It's hard to break into it if you're on the outside. Once there, I wouldn't say they incentivized pushing projects to open source, but they certainly didn't resist it in any way. One of the projects that I worked on there was around automated refactoring, and OpenRewrite started at Netflix. From the beginning, it was an Apache license and was open source.

You were saying from a top-down point of view, it was quite laissez-faire around opening things up, but from a bottom-up was that also like the main push? Are you seeing other teams and other projects in Netflix doing that? Was there a bottom-up community as well that was spurring each other to do this thing?

A lot of those components, Eureka for service discovery, had fame. These client-side HTTP request generations. There was Hystrix for fallbacks. Several projects were core to how they developed applications that had been open source. Netflix's compensation structure, in some ways, incented open source as well.

They didn't have an annual review cycle, but rather, at the time, it was all about paying individuals top of the market, which is what they would call it. The more public visibility you had as an individual, frankly, the more compensation pressure was on the company to retain you. There was a baked-in incentive to do open source, which is great, both for the company and the individual.

Also, the projects that you mentioned, at least the ones that I'm vaguely familiar with, were “dog fooded” to a complete, extreme degree within the company.

They weren't fundamental to the way that the infrastructure works there. It wasn't a project for the sake of it, but rather, it was a need that they had internally developed and actively used daily. With OpenRewrite, one of the responsibilities that wound up falling on engineering tools was around migrations at the time or planning them and trying to coordinate and shepherd migrations at the time.

Moving folks from Java six to seven to eight, moving people off of the logging library, fixing vulnerabilities, but alongside that lazy fair attitude towards open source, there was also this cultural tenant called freedom and responsibility, which meant as a central team, you couldn't impose any constraints on what product engineers did.

If you're going to build a solution that tries to move people forward, say, to a later version of Java by a certain date. Typically, the way people build that is by doing some reporting, dashboards, email, communication, and threats. If you don't move by a certain date, we're going to break your build. You have to move by a certain date.

That was anti-cultural there. The idea that threat could be part of the solution. Not surprisingly, we did a lot of work on reporting, trying to surface to folks where they weren't in compliance with where we wanted them to be, and it resulted in basically no action on the part of product teams. As you go around and ask product teams, what could I do? What information could I give you that you would move along?

They would say, “Do it for me. Otherwise, I've got other things to do. I'm not going to do it.” When we hear that enough, do it for me. There's only two of us on this engineering tools team. There's a hundred of them. It pushes you towards automation. I felt culturally required to build this automated refactoring solution.

I'm curious to know. I'm assuming because people, especially engineers like myself, always think about Netflix as the server or the server side requirements are off the chart insane. There's that famous statistic about the percentage of internet traffic they are and that was years ago. I guess they have dozens of obscure client platforms that they need to target as well. They also have requirements around security and how to upgrade them, as well as some old random TV operating systems. Did some of the refactoring automation drive come from the client side as well?

Not as much. Most of the code was executed behind the API gateway, so the clients were relatively thin. Necessarily since they had to be, if it was shipped to a TV, you may not have an upgrade path for a long time. If you're going to make changes, it had to be made behind the call to the API gateway, but behind that call were tens of thousands of repositories representing many different kinds of microservices.

The great thing about microservices, you ship a unit of functionality very quickly. The downside, of course, is you now scattered the upgrade path across thousands of different components. There's that give and take. You can contrast that to the mono repo world, where you have to move everything at the same time. It's the opposite of that. A lot of the pressure came from having to update the same.

‍

In terms of the origin of automated rewrite and refactor, did OpenRewrite invent that category of tool or were there ideas behind it that influenced what it was going to do? It's quite a radical idea.

Very much so. There had been some small attempts, and not surprisingly, there were those that had tried. You saw Google had created a technology called Error Prone, which originally was scanning. They had a variation on that called Refaster, which allowed folks to define before and after expressions in code. It would change the code itself.

Uber had a technology called Piranha, which also did refactoring to some extent. Facebook had a similar technology. When I looked at Google's technology, Refaster is an example. Google also had this mono repo, which had a very centrally top-down culture. All of our Java code is formatted the same. It's all in a mono repo. There's no stylistic inconsistency.

Based on that consistency, some simplifying assumptions could be made at the refactoring engine level. At Netflix, because of freedom and responsibility, it was the opposite. There was no stylistic consistency. People could use different build tools and different libraries. It was all over the place. Tabs and indents, of course, were another particular team basis.

Some of the foundational requirements that we had had to be style preserving. When I make a change, it has to look idiomatically consistent in the context of the repo or suggesting the change code. It must be accurate or the typical Netflix engineers are going to ignore it and not do it. “Do it for me. Otherwise, I got something else to do,” attitude. I didn't see those requirements satisfied in any of the other attempts to automate refactoring at that point.

Did you have an initial target project or task that kicked things off?

We had an internal logging library called Blitz4J. I don't know what year that was created, but it was SLF4J, the pretty common logging interface for most Java business applications at this point. Some years later, they regretted the existence of Blitz4J and tried to deprecate it. “Let's move to SLF4J. It would be a lot easier for us. We don't need to maintain this component.”

As you can imagine, they're logging statements littered everywhere through the code base. What highly paid Netflix engineer is going to come into work one day and think the best use of my time is replacing logging statements one for another one. It has the same output in the end. It didn't happen. There would be millions of these things littered throughout the code base.

There was that. There was also a situation with a library called Guava, which came from Google. Google would retire APIs every other release. It was almost becoming an existential problem for Netflix, and we couldn't move forward. We could not adopt later versions of libraries because they had transitive dependencies on Guava.

The dependency spread between a core library at Netflix and its requirement on Guava and an application was growing so great that things would break. We had to remove the API surface area that had been deprecated and removed so that we could eventually unstuck ourselves and move forward. There were several things, but those initial use cases were small enough that the framework could be tailored to fit those needs.

In terms of the sequencing and the history of it being published, I presume GitHub and starting to build a community around that. What was the sequence of events there?

The first task was that Blitz4j. Develop the framework. I did not want to write a whole parser from scratch.OpenRewrite, in its initial implementation, is still leveraging the compiler itself and mapping its data structure to this day. We call the loss of the semantic tree from the compiler's internal abstract syntax tree and its representation.

Then we went back and scooped up all the formatting information as well. Before we could make any change, the first thing was to prove that we could parse from source code, all of the Netflix code base, and tens of thousands of repositories, and then print them back out to source code without any modification.

We call that Parse to Print Idempotence. As you can imagine, several iterations on the technology to prove that we could do that at least and then the minimum set of necessary changes to accomplish that Blitz4j migration. How do we start pushing that out? That was unknown. Do you do mass PRs across the whole organization? How do people want to receive things?

That started a long process of grappling with the fact that different engineering teams wanted to pull it, and some teams wanted PRs issued to them. There are a lot of different ways in which change gets shipped to engineering teams to get them to ultimately accept the change.

At some point, after these first several changes, I had gone on to work on the Spring Team. I'd gone back to Missouri for a while. Working for the Spring Team, I founded a project called Micrometer for application metrics, a completely different industry or different area of software engineering, working on application metrics, then started working on bringing Spinnaker, which was a multi-cloud continuous delivery open source solution from Netflix, Google, etc.

We were trying to layer Spinnaker into Pivotal's cloud foundry products. It's a PaaS or Platform as a Service Solution. As part of that work, my cofounder Olga Kundzich and I went around major enterprises, working with them on getting Spinnaker into their environment and using it for continuous delivery. We thought we had something interesting: automated canary analysis, red and black deployments, and these kinds of things.

What we kept hearing from these enterprise customers was, “Yes, I'd love to do automated canary analysis, but talk to me in a year when I'm done moving Spring Boot 1 to 2 or this Java version of that.” They would always feel super depressed about it. I've got to move thousands of repos. That's going to take all my time. We heard enough that we thought, wow, that this capability that had started at Netflix belongs in some enterprise solution as well.

That was the genesis idea around Moderne,

The Genesis Of Moderne

That was the start of Moderne. We felt like it got pulled out of us from what we were seeing in one business after another, struggling with these migrations. It's interesting that even in large enterprises, the reliance on open source has increased substantially. There was one bank we were working with, and by the time we were done working with them, we had something like 8,000 applications written on top of Spring Boot.

Now, it's something 25,000 at that organization. You can imagine that anytime spring makes the Spring team make a breaking change, they've got to touch 25,000 apps potentially. That's enormously costly. That's what I feel has changed in 10 or 15 years this reliance on almost a componentized software supply chain. You could pull components off the shelf, build experiences, and ship them very quickly, but then what was the maintenance of that like? It was very manual still. The thinking is that we need some automated migration path or it becomes unsustainable at some point.

It's interesting as well. You accidentally do some early customer development almost without realizing it, which is probably a healthy sign for a startup business. If you're seeing that, I know with Flagsmith, that was like when we started. When we got our fifth or sixth inbound request from a massive organization, we want to run this ourselves. I've got to do something. I've got to take some action around this.

We see this as well at Flagsmith, with financial services or data-sensitive organizations, especially regulated industries, where they have a regulatory requirement around security testing and things like that. There's a business I'm involved in, another separate business that is still working on a very old version of an old Java framework. We've made some of that stuff public-facing, and the migration path is painful because there are many years of code there that we've re-implemented in the public bits in Django.

Then we're going to IP lock it out to a couple of VPN addresses and leave it at that thing. For large banks, that is an existential problem for their engineering teams. They criminally can't have this thing running on the spring version. Log4j was the perfect storm for that situation, talking about log-in being the OpenRewrite V1 thing and the calamitous situation with log4j. I'm trying to think of the timing, was that post after you found it?

Yes, That's right. I moved on from that, but I kept hearing those kinds of things. It certainly affects these large regulated industries, but even for ourselves or a series A company, we have SOC 2 compliance. We have to have SOC 2 for our solution. We have 90 repositories or something like that in our organization, some of which are private, some of which are public.

The easiest way to satisfy SOC 2 requirements is, in many cases, to move forward rather than listing out. Even for a smaller organization, that ability to move forward is important. There's another element to this, we're building, say, if we were building on Spring Boot, we may be a small organization, but that huge bank is also building on Spring Boot.

Even for a smaller organization, the ability to move forward is really important.

We have the same requirement. We have the same migration that we need to do at different scales. The question then becomes, who is responsible for providing the recipes? Recipes are the programs that make the change to move us forward from one version to another. I have a strong belief that the recipe should be the responsibility of the framework author who's making the break and change in the first place.

In other words, if you break it, you fix it. Of course, like anything, there's no requirement that they do so. We can't compel our framework authors to write unit tests either, but it's a signal that we're looking for as we look to select frameworks. Do you test your project product? Do you provide a migration path? If you don't, I'm going to consider an alternative that does because I recognize that this is part of the cost that I bear using your framework.

That's interesting. I've got this theory that software engineering doesn't do that calculation upfront when deciding on taking on a library or framework or whatever. I'm as guilty of it as anyone else. The thing that triggered this for me was on the SDK side of the Flagsmith landscape. If you are bringing in a third-party library, a feature flagging SDK, you want it there. Ideally, it has zero upstream dependencies, like in a perfect world, it would have none.

For every single new library that you bring in, there's a chance that there's a version collision with something that you're already using, and your security surface becomes larger. When we were building the flags with SDKs, and luckily, they're fairly simple, you could get away with using almost no third-party libraries.

‍

Different languages are interesting, and some languages, like Python, have a pretty de facto HTTP library. Java might have several, but it might have one that's asynchronous and one that isn't. I became obsessed with this idea of taking everything all these dependencies out of the SDKs and stuff. It suddenly started to make me realize what instances of someone bringing in a library are. Flagsmith is the same.

It's a couple of rest calls. You could avoid our library altogether, pretty much if you're willing to do that. That's a slightly trite example, especially if you're bringing in something as large as Spring Boot. For example, I can't imagine those financial services organizations, and they love you to fill out forms of doing builds or migrations.

They have a form that you want to start using a new framework. What are the controls around that? The folks reading this who work there in those sorts of jobs are probably another last thing I want to do. My point is, at that point in time, it's free. All that code and all of that functionality is free, but the debt is very often not considered.

It is a situation where we don't have a choice. If the software development ecosystem has been commoditized to the point where I can get an application up and going quickly and ship a feature, then I have to be able to do that. The fact that it imputes debt, on the other side is I don't have a choice. I can't build it all from those principles, and I have slower feature development, either.

In that way, the word technical debt or phrase is interesting in that we often think of technical debt as something that we put upon ourselves like we're trying to ship something quickly and therefore, we cut a corner and we're going to have to come back and address this at some point. There's this other technical debt that is foisted upon us from the outside via a breaking change from a third party that we required when we didn't have much choice whether to use either that or some similar third-party library anyway.

We often think of technical debt as something that we put upon ourselves. However, it’s more often foisted upon us from the outside, from a third party that we require when we really didn't have much choice, whether to use either that or some similar third-party library anyway.

Some forward organizations are calling that maintenance, rather than technical debt, which is a different thing. It's something I did to myself as opposed to something that's been done to me on the outside. It's that maintenance work that we need to systematize in the same way that we've systematized the use of third-party stuff.

That's a great way of putting it. It's unconsciously taking it on rather than normally you'd say, “I'll make an active decision not to do this code, not to write that code, or not to refactor that or whatever.”

If this is the world that we live in, I need to be able to take advantage of this industrialized software supply chain. I'm pulling components off the shelf and using them. The maintenance needs to be automated as well. Otherwise, that becomes unsustainable, which is the state that we're in right now. Another element is to recognize that the industrialized software supply chain is very broad.

It's not one library. As you said, there are five HTTP client libraries. That's for one thing. You've got unit testing, you've got feature flagging, you've got vacation development and database access. There's all these different things. If we're going to provide automated migration path or tooling, that tooling almost necessarily has to be open source and not source available, but open source in a way that's commercially repackageable into different products.

Otherwise, we will not get participation from framework authors who are writing those migrations. Why would they? Why would they write a recipe that benefits only one organization? As we went to set up Moderne, we had this stance and it's been somewhat controversial that OpenRewrite and all of its recipes, all the things that make the change have to be Apache license.

We need to build yet another product that's on the side that adds value in a complementary way because if the foundational recipe itself isn't open source, then what chance do we have of coding such a broad ecosystem? Yet here we are. We're a fledgling company, and we're taking a strong stance that the recipes and migrations should be Apache-licensed.

The community could look at us and say, “We've seen this story before.” We've seen Elastic, Mongo, Redis, and HashiCorp most recently start with these commercially permissible open-source licenses and then change them at a critical moment of their scaling. They'll change them to business source licenses or some form of LGPL or something of that sort.

In large part because hyperscalers come in and compete with the company that's running the open source project. People could look at us and say, “It's an Apache license for now, but you're going to change that, inevitably.” That becomes a barrier to adoption. That's where Commonhaus is interesting. I had this friend at IBM, Erin Schnabel, whom I've known for several years.

She asked me one day and several other folks. I'm thinking about starting another foundation because I feel like there's a gap. There's a gap where if we look at the open source foundation landscape, think of Apache or Eclipse. They're famously heavy-handed about how the project is run and how it does voting and releases. It's difficult to get a project through the Apache incubation.

On the other side, you have CNCF, which is hundreds of projects that feel a little bit commercial at this point. You have a continuous delivery foundation, which feels a bit narrow in scope. They have a Linux foundation. All these foundations have different characteristics, but the characteristic I want is no governance. Don't tell me how I'm going to do releases and voting and acting contributors.

Moderne & Openhaus

The trademark for the project, OpenRewrite, in this case, passes to the foundation such that if, as a commercial entity, I ever decide I want to take this closed source or source available but not commercially permissible, then I have to fork it as a business. In the HashiCorp scenario, Open Tofu would have been HashiCorp's product, and Terraform would have been where it is now. That is interesting. The key thing in what they call succession planning is that the actual trademarks of the product go to the foundation. If I ever abandon it, the foundation can transfer ownership somewhere else.

‍

Is this something that is enshrined legally within the license of the project or is this a pledge that the project makes? This is one of the other things as well that is interesting for all of the great aspects of open source and the progression of different types of licenses in the open source world. At the end of the day, the 4 or 5 projects that you mentioned, the famous ones, it turned out that it was their word. It was to the people who ultimately have the right privileges to the repository or whatever. At the end of the day, the licenses didn't make that much difference at all to anyone's certainty around anything.

It is legally enshrined, not in the license itself, but in the formation of the foundation. In the foundations, core documents require that a project in the foundation transfers the trademark ultimately. That is the key missing piece. It's small. It seems like that's the piece that I'm sure I could fork. I could abandon the other project, but I'm going to have to create Open Tofu.

I keep Terraform changing the license and somebody else creates Open Tofu and then all the brand recognition problems that come along with having to broadly announce, “By the way, the name changed.” Those sorts of things. To me, that ends the conversation once and for all. It is like if I go out and get hit by a bus tomorrow, nobody who succeeds me is going to be able to change that license effectively.

That's what is smart about it. It's low on governance, but this transference of the trademark is important to give that assurance. The other projects that started in Commonhaus when it was first announced It's almost scary when you think about projects like Jackson, which is used pretty systemically throughout the Java ecosystem for serialization. It's not baked into the language. It's a third-party library. It's one tattooed guy who's been working on this for fifteen years. It's a reliable person. It's one guy, ultimately.

That's why the Nebraska cartoon is real.

The other projects that were out there were dangling like that as well, such as Hibernate. If these big foundational dependencies were abandoned, I don't know what we would do.

My background is Java and for those young kids reading, the projects you're reading off are huge, titans of the Java library ecosystem. Hibernate changed my life. It stopped me from writing SQL programmatically and things like that.

These are the projects that we're now seeing come in that previously didn't want to go to Foundation, didn't want to go to Apache, or didn't want to go to Eclipse because it was such an honorous effort that now there's an easier transition path to that. What I like, too, is that it doesn't have to be in the end state. You can have a project that says, “I'm interested in formalizing this license on an ongoing basis.” I'm going to start in Commonhaus. Maybe someday I go to Apache, but I take on that additional governance requirement. Rather than having to chew on both at the same time, I can do the license assurance first and then governance, which I can think about later. That's interesting, too.

One of the other things that Commonhaus talks about is fiscal support for projects as well. Could you talk a little bit more about that?

For OpenRewrite, having a commercial entity behind it is not as important, but for a Jackson Hibernate, it is not against the situation of a library maintained by a guy in Nebraska who is tattooed in Seattle. Maybe financial support is more important than continued involvement in the project. The goal Erin had around Commonhaus was rather than having a lot of spending on marketing, and this at a foundation level, any donation, participation, or contribution to the foundation is going more towards supporting those projects that need that financial support.

In terms of jumping back to Moderne, how does that fit into your life outside of outside of that business? In terms of OpenRewrite, what's its relationship to those other projects that you're working on? For Modena, how does it fit in with OpenRewrite?

If we think about open source businesses in general, there's been a lot of talk about open source being something you can't build a business on. Let's go back to those examples first of where it hasn't been sustainable in the end, Elastic Mongo, Redis, and Apache Corp. The common feature you see in a lot of those businesses is that they're often databases and have the core product.

For Kafka, that's in open source, and you can operate that database or that message bus or whatever it may be on your own. You can also say, “I'm going to offload the operationalization to somebody else.” That is what the commercial value proposition is. I'll operate it for you in my cloud. You don't have to worry about this. We're experienced at doing this. Maybe we add some other commercial enterprise features on top of that, like a different authorization or whatever the case may be.

There's always going to then be feature pressure, what belongs in a commercial feature versus an open source feature, but the moment you have a model like that, and those are broadly called open core solutions, where you have that core product that's open source, and then you're operating on the other side. Those are the kinds of businesses that hyper-scalers tend to destroy.

The moment it becomes important enough economically, Amazon can operate as well as one of the core companies. That competition naturally emerges at a critical inflection point. From the beginning, we said that we could not build an open-core business. It has to be something more like the old Jule Wolske article on commoditizing your compliment.

We need to say that we have an independent value proposition. It's almost like we're building a second technology. We're commoditizing something else. In our case, we want to commoditize the description, of how you define a migration. That's an open-air recipe. The product on the side has its commercial guardrails. The ability to take that data structure, the loss of semantic tree and serialize it to disk such that I can run that recipe across 200 million lines of code in a short period.

That serialization is what we've guarded as commercial intellectual property. You can take the same recipe and run it with open-source build plugins, where you're paying the cost of parsing the LST into memory every time for every repo for every run. People do that, but if you want to operate much more efficiently and it's scaled. There's a different solution.

What that leads to, like in our case, Moderne can build multi-repository experiences in a world where we're used to very single-repository experiences. Think about GitHub. GitHub is a very single repository-oriented thing. Its PRs are a single repository. Issues are single repositories. Commits are a single repository. There's no real like, “How do I commit to multiple things when I recognize that I'm responsible for 200 repositories, not one.”

Open source is limited to parsing into memory, one repository at a time. People who build alternative commercial solutions on top of OpenRewrite, like Amazon did with Q code transformer, tend to build them in a single repository manner there. I can run this on one repo at a time. We had to decide the time to tell whether we were right. I guess that multi-repository experiences were significant enough in value that we could build this complimentary product around that. That means that there's no pressure on us to say this recipe is a closed source. This recipe is open source.

Was that easy to find, pull out of the air, that commercialization dimension, or was that hard to figure out?

That's where Olga and I talked a lot before we ever embarked on this company. We had to have a formational thesis that multi-repository was important. I don't think it's obvious. I'd seen it on Netflix. We're trying to deal with 20,000 repositories. If I'm building a recipe, how do I know whether it works on 20,000 repositories? I need to be able to run it on all 20,000. We had seen it at these large organizations we were working with as we were layering in Spinnaker. We had some information about that.

What are the projects that you're involved in? What's next for Commonhaus and an OpenRewrite in Modena? How do you figure out how to split your time between those things?

It's tough. Part of the challenge of building a commoditized compliment, open source company is that effectively you take on building two technically difficult products. One is the open source. One isn't hard enough. Let's do two. Of course, you get the benefits of community involvement and the brand recognition that comes with supporting that one technically hard product, but you do have to build another one, too.

We have our team, engineering team split along those lines. Some people are dedicated to OpenRewrite alone, and some people are dedicated to Moderne products alone. That's part of the cost of doing business for us. As far as the framework goes, the exciting development this year was that we recognized we have to expand languages.

We started in the JVM or Java ecosystem and then started doing infrastructure codes. We can do Terraform modernization or fixing. YAML, of course, Kubernetes, YAML, modifications of migrations, JSON, those sorts of things. We took a step back and did COBOL LST, believe it or not, and about 31 related COS technologies.

Now, we have to add support for C#, Python, and JavaScript. It's very important that we provide the ability to write recipes in the language you're trying to transform. I'm going to go to a C# developer. They don't want to write a recipe in Java. They want to write it in C#. We do have a technology now that allows us to do that.

C# will be the next language that arrives next month, where there is a C# native recipe authorship experience. The other important thing to making this work, in general, is that the C# LST, the Lossless Semantic Tree, extends from the Java or J loss of semantic tree because, at a syntactical level, even though they look different in code, they share a lot. An identifier doesn't matter.

Base recipes that we wrote in Java, like change method name, change method targets, and things that were written for Java, automatically work on C# as we add that language by the fact C# extends from the J LST. We call that a grammar island of self-similar languages that share the same syntax, more or less underlining it.

There's this C family of languages that share that same syntax and those on that island are like Java, of course, and Groovy and Kotlin, C#, Python winds up on the same island, Ruby, believe it or not, JavaScript, and TypeScript. There's this interesting world where a Java developer writing a recipe to migrate Oracle to Postgres benefits a C# application. From Oracle to PostgreSQL, I don't think I've seen that language level sharing ever.

That would be unique to me as well. I can't think of an instance of that being the case yet.

Our ability to ship that LST over process boundaries and have programs written natively in different languages to make modifications is the key to the reuse necessary to make this scalable across languages. That's the most important thing for us.

Have you figured out what the language sequence is going to be? Is that contentious within the organization?

That's right. C# is our July 2024 release. That'd be the first language where we see a native recipe authorship experience that shares the model and a common substrate with the Java LST recipes. After that, Python will be probably in September 2024, and then JavaScript, and TypeScript right after that. With those four language ecosystems, the JVM, C#, Python, and JavaScript, we've covered a lot of the commercially relevant segments. We do have a Ruby parser already written, and that one will come for free, more or less, to us at the point where we deliver one of these other languages. Then, what should be next beyond that? What's the next most relevant thing, probably go LANG or Swift, I don't know.

We stopped at Elixir in terms of SDK support. I can't remember the last time. We assumed naively that the Dot Net client would be okay, but they've got different threading models and you can't assume that all of the client devices can run all the libraries, but we've done enough now. It's the same with the dependency that I was talking about. We're now very delicate about adding another language, framework, or platform support because it multiplies whenever you want to make cross-platform changes to all those languages. You multiply by one.

When you get to eleven. We're at eleven. The difference between 11 and 12 isn't that much, but it's tough. Jonathan, thanks so much for your time. It was fascinating talking to you. It’s interesting, fairly hardcore computer science going on in that project and that organization. Before we go, I guess there are probably several places, URLs, or communities where, if people want to learn more and get in touch, what might they be?

For Moderne, it's Moderne.io, and for OpenRewrite, the easiest place to start is Docs.OpenRewrite.org. Those things are all connected. If you get to one, from there, you can get to GitHub. We welcome participation in that ecosystem. There's a Slack in that docs to open or ignore so people can ask questions there and forth. You can get connected.

Then Commonhaus is in German spelling.

That's right. Commonhaus, that's Commonhaus.org as well. We announced four more projects joining. EasyMock, which is pretty used quite a bit. SDKMan joined. Objenesis has a history of causing changes or breaking changes over Java versions. The project continues to grow, and I expect that it'll ultimately grow outside of the JVM ecosystem as well.

Jonathan, thanks again for your time. I look forward to seeing what happens with those projects in the future.

That's right. See you in a couple of days in London.

Yes. Cool.

‍

Important Links

• Moderne
• Docs.OpenRewrite.org
• Commonhaus.org