Painkillers before vitamins with Juri Strumpflohner

Jack: Hi, this is Jack and you're listening to Scaling DevTools today by Juri who is the director of developer experience at NX Yuri. Great to have you on today.

Juri: Yeah, thanks for having me.

Jack: Yuri, could you tell us a little bit about NX, and NRWL and your story?

Juri: Yeah, sure. So NRWL is basically the company and, NX is our open source product, let's dive a bit into what NX actually is for people that might not have heard about it. So an is if you want, a smart extensible build system. This kind of abstracts if you want, or sits at top of like things like web pack or is build or whatever you are using underneath.

So it basically helps you run those tasks in an efficient manner. And that said, and NX is kind of, has been designed to work on small projects. Let's say you have like your small react application that you wanna create with it, to really scale to large, large, multi-project repo or monorepo as they're known and.

That's what, what NX kind of does. It comes with a lot of different features an approach that we could kind of dive into more detail. But basically it provides an easy, incremental approach. And in the sense that it can incrementally adopt an X very easily gets started with it very quickly.

But then it has also a second approach where you. Use and benefit from its huge plugin system. So we have kind of those two things that people can get started with it.

Jack: Amazing. And the founders of NX and NRWL were experiencing this problem themselves. Right.

Juri: yeah, yeah, the founders of novel is the company behind NX. they are ex Googlers. And they happen to work on angle team as well. and so, when they left, like what is inside, Google is like how Google developers, right. And Google is known for having one gigantic mono repository with all the products in there.

And they have obviously dedicated tooling to make that work. and why are they using a monorepo simply because they see the benefits, they see how it helps people collaborate, how it helps ship software faster. So you get some more consistency across different projects, right. Especially if you integrate between them.And so basically Google has developed custom tooling just to make it work at, that scale. And so internally that tool is called bla and externally. If there's an open source variant of it, which is called Basil. Which is a very powerful tool, but it's arguably also kind of complex to set up.

So, huge, huge companies sometimes have dedicated teams to actually use basal and set it up in their environments, and, kind of maintain it over time. Cause it needs kind of some, some dedicated folks to actually take care of it. And so when, when like our co-founders, Victor staff and Jeff Cross.

Left Google to build their own company. They wanted is obviously the opportunity that something like that in the open source space, and in, in companies outside of Google, might be beneficial. but obviously taking it from a more lightly easier approach, . In the sense that you don't wanna necessarily have to have a dedicated.

Tooling team just taking care of your build system tooling. Right. But it should be easily approachable, but still work at scale. So that was kind of the challenge. . and so yeah, from our perspective, they started doing a lot of like interacting with those companies. A lot of like how NX.

Kind of got built and kind of evolved over time. And we can maybe dive a bit deeper into that was mostly by doc feeding back into the project, what we saw when we talked to clients. Right? So when we talked to them, we saw the problems that they faced, the problems that they had. And in return, basically we base continu to evolve our open source project, to make sure to, to address those specific problems.

That is more or less approach that, that has been taken.

Jack: That's really, really interesting and uncommonly in the developer tool space, you are completely bootstrapped at the moment. could

you talk a little bit about your business model?

Juri: As you mentioned, like the company's C bootstrap, so they started basically, like we were currently self-funded so Victor and, and Jeff started the company mostly out of a consulting business initially. So given that they worked ATR team, they had some, good connections also in community.

So initially a lot of the business side was pure angle consult. and then obviously S on the side, we kind of grew the open source charge and NX, and given a lot of companies wanted to go into that monorepo space and X was always, or more as a big part of, of that consulting. So when we work with companies, most of the time NX is what we use there at the company, help them set it up, help evolve in NX and kind of.

Help them develop quality code. And the big chunk was with angler is still with angler. And over time we kind of grew into a react space simply because basically following along how the front end space kind of changed and, and kind of got involved into more like anger react project and whatnot.

That was kind of the approach. And even now most of like our business model is structured over providing consulting services to companies, In the sense that helped them develop anger or react applications as well as obviously help them set up NX. And fine tune NX customize an NX to what they need. Because an NX in general is, isvery flexible, so, what happens nowadays often is that companies actually reach out to us because they have already an X in their corporation in their organization. and they want to just fine tune it to what they have the according to the processes and like business process that they have inside.

Company of how they develop code, And help us fine tune an NX to work better in those situations, by developing custom plugins, by helping just fine tune them and coaching them how to actually customize the NX. So things along, that way. and then there is obviously another thing that we introduced on top of an NX, as second approach in terms of our business model, which is like NX cloud.

Which is providing remote caching, remote task execution, and it's subscription based model. So especially targeting mostly large companies which want on premise installation of that. And so we help them set it up and sell that basically that type of engagement, which works pretty well.

Jack: That's really, really cool.Yuri. So NX now has you mentioned 2 million downloads at least reported by MPM per week. And you have like Fu thousand GitHub stars or more, how did you go from this open source project idea to. Being such a popular project.

Juri: First of all, a lot of work went into what NX is today, right. But it kind of grew organically over time. So when I mentioned initially that our business model consists a large chunk of it, at least consists of consulting work. That also means that we don't. Work full time the whole week, just on NX as the open source project. And so now we start transitioning some developers more to go full time on NX , as we want to kind push it more. But like, what has happened in the past is that people would like four days a week work on consulting, helping companies grow their business, using NX, most of the time, at least.

And then one day a week they stick focused on actually pushing forward, open source project. So you can imagine that just 20% of the time it actually went into the product. But at the same time, it was a lot of valuable feedback. And so given it was 20% only, it kind of grew organically over time.

But always kind of feeding back into what we experienced, like when we work with those enterprise clients, the pain points we see there. And at the same time as the community and the open source community, where we were very, very strongly connected to getting also funneling back that feedback from that open source community.

And so that's kind of how we grew over time. And I very much like, as I mentioned, like, kind of quote that Tony Fidel, like he's the co-creator of like the iPod and the iPhone. Like he had like a saying where he said, like you, when you develop a product, you need to create the painkiller first.

So you need to identify the pain points and provide painkillers. That's what you should do. and not necessarily the vitamins, right. Because that's like, you don't wanna start with those. Cause then the product's not that appealing. And I very much like that analogy specifically because I. That is the approach that we took, with an NX to some degree.

Right? So we working with those companies, seeing what the community kinda asked us, right. Reached out to us, Funding that feedback back in, we clearly knew what pain points were. Uh, and so especially talking about that, for instance, like when you approach a monorepo, you don't just wanna naive to jump into. Because then initially it works well because like it ours. Cool. Like you can share code very quickly among team members, but what a lot of people see then over time is that build get slow. UCI now takes not just like five minutes, but it takes like 30 minutes an hour. And obviously then you get , the, reverse effect, right from the initial productivity gain.

Now you get actually quite drained in terms of productivity because you have to wait an hour or so for your PR to merge And so that's, what we saw very quickly early on that you need to have tooling that helps you tackle that. And so that was one of the pain points, for instance, where we heavily focused on.

To make sure that works as quickly as possible. And so in an NX, for instance, we introduced things like identifying the projects that got changed in a certain PR or something. And just run the actual commands for those. And you can imagine how that already kind of cuts down a lot of things.

Because if you have , I don't know, a hundred projects in there, but you just touch a couple of those where there's no point of running the build and test for the hundreds. But just for the ones that are connect. And so that helps you already optimize. And on top of that, like over like various iterations, we added things like more optimized prioritization and running the task in a certain order that is most efficient to adding like things like cashing, which means that you don't run a project that didn't get changed over time, or didn't get like changed in terms of the relationships with our project.

And so we just got restored from a cash. and to the point where we added like the NX cloud on top, which is the subscription based product, which then adds like distribution of that cash. So it's not just your local workspace, that cash is your own runs and commands, but actually the system can use it now.

and especially even for yourself, for instance, let's say overnight, you have. To build system on CI that runs and builds everything and, and kind of feeds the cash. Well, next time in the morning, you go to your developer workstation, you're connected to their cash. So you are not gonna run the test locally because they will just like restore it from the cash you be basically instant.

And so obviously it gives you also like very good feeding as a developer and a lot of productivity. Giving those things. And so those are painkillers because you direct the address. What is the biggest pain point that you have when you want to start with a monorepo? But I would say like coming back to that analogy, for instance, that vitamin part and NX comes also with those vitamins, because it's not just.

Getting started quickly and just addressing those pain points, which obviously are very important, but you also need guidance along the way as you grow, for instance, in mono or as you keep developing over the years. It's more of a marathon, right? Like, especially if you're a large company, you have to project, you have your product, but you wanna maintain 'em in the long run.

So it's not just like the first six months. That should be good, but should be like a couple years. That should be. Quite nicely. And so next comes with a lot of features there in terms of helping generated code, helping you, like it comes with a plugin system that like facilitates the creation of new projects.

it helps you also with things like automated migration, for instance of the tooling underneath, which is something which is super underestimated, but we all know like upgrading tooling is not something you usually get easy budget for when you talk to your project manager or something. . So things like that come built in with an NX.

Uh, which are very beneficial, And so, so that is kinda, I, think like by addressing those pieces over time, that helped us grow a lot because it simply more and more people saw it actual benefit. So they started using it, they started trying it out. and then organically over time we started growing.

there's also the point I think that is important to mention is the whole kind of open source and community involvement. So we are very like, since NX integrates, it is opensource, first of all, from the very beginning. So we never had a private product which didn't work out and that like kind of transitioned to an open source model.

Our founders are very much like into. No, this is important for us. Like they already worked on anger that was open source from the beginning. So they kind of wanted to engage that model and keep that pushing forward, which we all know is kind of sometimes challenging in terms of the financial aspect.

And the sustainability. but for us, it's worked out quite well. The company's now. Over five years old. And, and so we're still growing quite a lot. as you mentioned, like we, we just hit the $2 million per week, just like month ago, which we nearly doubled in the last six months. So the growth actually, which is probably more important than the numbers is, is pretty.

Pretty working out nicely. but yeah, it leads a lot of involvement in the community, and since we integrate a lot of different projects from the community, let's say if you set up anx project, for instance, nowadays, like you get integrations such as Cy percent to testing out of the box integration with just unit testing, Lin set up, like you get all those things plugged in.

And as part of that, since you want to make that work in the best way possible, we talk to a lot of those teams. So we've been constant, like connection with them. We have private slack channels with them where we exchange experience and they give us a heads up of new features that are coming out. And so we can already start working on them, which is kind of mutual benefit, Because at the same time we test their features, but we also are prepared to actually have that ready when they release or launch it. Uh, which I think is very, very, very beneficial.

Jack: You mentioned in our previous discussions that you hire a lot of people who are a big part of the communities that you work with. Could you touch on that a little bit?

Juri: I think like one important aspect or one interesting aspect of, novel as a company is that we have a lot of people that are super active in the community. So like, in my case, for instance, I'm responsible for the whole develop variations part, the develop experience, like integrating with the community.

And I'm, to be honest, like I'm very lucky because we have. Engineers that have their main focus area is engineering. So they work in a product and improve the product and provide consulting, but they're very attached to the community as well. So we have a lot of Google developer experts on our team.

So they are accustomed to speak at meetups at conferences and simply interacting with folks. And I think like from a growth perspective, especially when you talk to community and want to grow the community side of things, that is very valuable, those are people that are already known. They have their own kind of community that are being followed by and, they interact with, and so obviously that helps also then promote your own product in the sense that NX in this case.

so yeah, I think that's very valuable. I appreciate it a lot because like, I don't have to be on every podcast and every conference, because like they're super happy to jump in and, submit CFBs to conference and stuff. So most of the times, even they reach out to me, oh, I was accepted to that cool conference going to be there and then talk about the next right.

Uh, which I think is we very lucky to be in that position? And it's also very refreshing in the sense that, having those different features, in people, right. When they can deliver good engineering work. But they're also at the same time, very engaging in the sense of working with the community.

I mean, my myself, I started. Focusing as a JavaScript architect doing consulting with Naval and working mostly on engineering aspect, while the only reason that transitioned more to talking more engaging with the community and, and doing that type of work. I think that is very beneficial if you wanna grow in a community, and helps a lot for sure.

Jack: And one final question, you told me offline about how you have actually taken over another open source project. Could you tell us a little bit about that?

Juri: Yeah, exactly. So we took over stewardship of Luna. Luna is, probably one of the first jobs. Good based monorepo management tools. It has been around right for a super long time. and so what happened to Luna basically is that I think two years ago it kind of stopped being developed actively because simply all of the burn basically finished up at the, the shoulders of one single maintainer, which understandably got like burned out by it because there's super huge, burn to take right to, because you get constantly pushed by people about new features and back fixes, and, and mentioning that like learner

it's quite a large project, right? It has about, I think 1 million, one, 2 million downers per week. So it's not like a toy, small toy project. It's actually being used by larger organizations and like open source projects. So you can imagine like the amount of like conversations and issues that are being opened.

Uh, and so two years ago that developer kind of stopped working actively, also because it wasn't their free time. Right? So it's, it's a huge burden to take. and only then later I think in may someone actually opened up a PR. Like in big letters at the top of the readme of the GitHub reboot to mention that look learner is not maintained anymore.

It's kind of, you can consider it obsolete and deprecated go search for an alternative, right. And there are alternatives. Like, meanwhile, there's like things like yarn workspaces, which, which gives you some support similar to Luna and PM workspaces, obviously NX like on our side. And there are also all tools like Topo and others that, that kind of merge recently.

We had already very tight integration with learner. So we saw two years ago that learner was. About to be deprecated or people wanted to go off of learner. and so we provide an easy way to integrate and, and that's, that's kind of what I mentioned initially, that an. You don't have to use the whole plugin system that comes with NX, although from our respect, that's kind of the best practice approach where you could most benefit in the long run, but you can also easily just use NX just for speeding up your repo, just running tasks in efficient manner, get cash in prioritization, that thing.

Right. And that was exactly what a lot of learner users complain because learner works well. The only downside of it was. It's not as efficient as you grow the workspace. So speed was a big pain point for the learning users, if you want. And we had a solution for that. Right. And so we provided the migration path where it could integrate an NX easy.

And when we then saw it, as it is being deprecated, we were like, It's kind of a bummer, right? Because a lot of folks that we also talk to, they are like, it works well for us. Right. We, we have quite a large learner set. We don't really want to band on it, but like obviously if someone mentions this is obsolete, won't get security patches in anything you're kind of forced to search for an alternative.

And then we started engaging and talking to the maintainer, how, like what that we would be possibly willing to take it over in terms of taking over stewardship. Um, we kind of evaluate on our side how much effort that will. cause obviously. Not just from a technical perspective, but you also kind of need to move forward, like refresh it, make it kind of re revive the project that was already kind of that for two years.

but it was a bound for us, like to kind of see it die and just like have people migrate over. And so we were talked to 'em and they were super happy. We explained them our philosophy, what we had already done because an at that point was already like four, four plus years, I think an open source community.

and also general our approach to open source. I mean, we sponsor a lot of our, our open source products we integrated with. So we were very attached to the community, so, and they were happy about that. so they didn't feel like they give it to someone that is going to then destroy it and sell it or whatnot, and just leverage the user data or I don't know what you could possibly do with it.

so it a good fit for them. And so we took it over in, in end of. Since then we've released a new version. We've released learn a five. We have refreshed website, new docs. , we have also integrated it, or we give people base the opportunity to use NX underneath very easily by just like flipping a flag, which we have seen.

a lot of positive feedback about that. And that's maybe also one aspect we could kind of touch because it kind of ties into the community building and stuff. Now, if you like take over stewardship of such large project, you wanna be very cautious about how you approach that. Right? Because we knew our intentions, right?

We, we are very attached to open source community. We wanted to push that forward, which is ultimately the reason why we took over learn the stewardship of, of that project. But you want to make sure you communicate that, Cautiously, if you want right. To not let people be in a position where they're like, oh, it's going to beaten up or something like that.

So we, our, like we were currently figuring out the whole strategy in the long run, Obviously integrating with an NX was one of the, the easiest things to do for us. And from our objective, it was also something where it would give people a lot of the benefits because they can have the same setup that they have right now, which is already working for them.

And they're happy with it. It just gets much. In a sense, because an NX works underneath learner gives through its own commands, which you don't even have to change. It basically translate them into an NX commands underneath and then speeds up the whole pipelines and stuff. And you could even use things like, as I mentioned before, remote cashing with NX cloud on top of it, that would totally word.

The feedback that we got is, is huge, like very positive. We were kind of initially a bit worried about like potential negative feedback. People like complaining, oh, it's gonna be taken over, screw it and whatnot. Right. but the feedback was actually very positive. A lot of people upgraded to latest version.

Integrate with an NX. And we have also some, some cool project like Redwood JS, which just upgraded and integrated with anx cloud. And we see new products emerging every day. So, I think it was very, a big success because they didn't have to abandon it. They, I mean, they still could. Right. They still could just migrate to another one.

Um, but it's not that much like of a pressure anymore because, it's not fast. It works, it has been security patch and everything. So, and, and we are obviously committed to push it forward. .

Jack: That's super interesting. And I think that's what we've got time for, but it's been incredibly interesting speaking with you, Yuri. And I know for myself next time, I'm building even a simple app with maybe like a front end and a back end. I'm gonna try out NX. I'm definitely sold on that. Where can people hear more from you?

Juri: Yeah. So the best way would be, to go to our docs, which is annex.dev. We're currently also working on that very intensely because we all know who docs are super hard. But that's the main point where you would. , be able to get in touch, get started with NX. Then there's our Twitter handle, which is NX dev tools, everything together on Twitter.

And we recently also push a lot of content on our YouTube channel, which is on youtube.com/nrw L OnCore IO. , and maybe we can link those in the show notes, but that will be the place where you get like the latest. Content to get the latest news, because most of the time when we have new blog posts and stuff, we promoted over Twitter, , or our YouTube channel.

And one last thing as very important, we started to have, some remote conference organized last year and also this year in, and now we actually announced, in-person conference, which is happening in October seventies. You can go to Anex slash conf to get all the news there.

We we'll soon announce the speakers and the workshops that we will have there. If you're excited about those topics, tooling, front end development, and monorepo definitely check that out and, and come and say hi, that would be cool.

Jack: Thanks Juri. And thanks everyone for listening. See you soon.