Ep. #134, Commercializing Open Source with Victoria Melnikova of Evil Martians

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Victoria Melnikova, how are you doing?

Victoria Melnikova: Hi. It's nice to be here.

Brian: Perfect. Yeah, do you want to go ahead and just introduce yourself to the listeners?

Victoria: Hi, everybody. My name is Victoria Melnikova, I'm the head of new business at Evil Martians. Together with my team, we work with growth stage startups focusing on developer tools. We transform those startups into unicorns. Together we build developer tools, create awesome open source products and do that sort of thing. I, in short, generate opportunities for us.

Brian: Excellent. Yeah, the opportunity that you generate and the space that you're in, it's literally the in between of a lot of the guests on this podcast. I talk to a lot of open source maintainers, from my background from GitHub, working at Netlify and now doing Open Sauce, and then dev tools like Heavybit being the shepherd, the host, the network of this podcast.

Tons of dev tool startups have come through Heavybit and have succeeded, very successfully. Can we first touch on Evil Martians? Because that was something that I've heard of Evil Martians and I've seen the work out in the open, but I never actually looked to see what is this team? What do they do? So can you give us a quick, little run down on what Evil Martians does?

Victoria: Yes. Evil Martians is a team of about 50 people. We are a software development consultancy with a focus on developer tools. Basically we do full cycle development, starting from product strategy and design, going into frontend and backend development. We also do machine learning and SRE. We work with 20 to 30 growth stage developer tool startups every year and we try to push them in their journeys to success, basically.

What's so special about us is we are a team of senior developers and designers who know the industry really well. Historically we've been known as a Ruby on Rails development shop, but we go much beyond that. There are two main pillars of our philosophy which are open source and education.

Many engineers know us because of our strong technical blog. We get about half a million technical readers annually on The Martian Chronicles. It's a great resource not only on Ruby on Rails stuff, but anything that has to do with development and design. That's us in a nutshell, but perhaps you might know us from some of the open source projects like PostCSS, Browserslist, ImageProg, Anycable. We have more than 100 open source projects that are widely used.

Brian: Yeah. I didn't know about PostCSS. Honestly, I've been using PostCSS since almost the creation. I worked at Netlify, we used PostCSS internally for pretty much everything that touched CSS. It was a conscious effort of moving over to this latest stage CSS in our projects, so pretty cool to hear about that. Also, I guess that's why I've seen Evil Martians a lot because of Ruby on Rails, that was when I got my first step into for programming so more than likely that's why I saw Evil Martians my entire career as a name, but never really looked into it.

But I'm interested into digging into the commercial open source side, especially the overlap, the concentric circle of dev tools. Commercial open source, can you explain that real quick for folks who are listening as well?

Victoria: So Evil Martians as I mentioned create a lot of open source projects. We have more than 100 projects, and because we work with startups a lot, we try to implement our product expertise and apply that startup entirely to open source. Basically what we try to do is we try to commercialize projects and the reason why we do it is because perhaps commercializing open source is the most sustainable way to do this business long term.

Let me explain this. Open source is intense. When you have a project that, let's say, it's a painkiller and not a vitamin, so it's something that many people use. It's really important to maintain it over time and that maintenance takes the soul out of you. People who maintain open source projects know that the burnout in the open source industry is very much real, and commercializing it is basically one of the ways to battle that burnout.

What we try to do is when we see that a product or an open source project has traction, we try to commercialize it and there are very feasible steps you can take to achieve that. It's been our mission to educate our audience on how to commercialize projects, open source projects, how to do it in a way that can bring you results fast, and how does it perform over time. One of the examples that I admire a lot is the example of Sidekiq. People in the Ruby on Rails space know that project very well.

Mike Perham, the creator of Sidekiq, has done it right. He has commercialized Sidekiq, I don't know, a decade ago and he managed to make it a super profitable business that is well maintained and just growing over time. This year he's approaching like $5 million ARR which is crazy for one person show, and it just goes to show that it is possible to do sustainable open source and one of the ways to achieve that is through commercializing it.

Brian: Yeah. I'm familiar with Mike Perham too, as well. I actually met him a couple of times through conferences and through GitHub, and it's fascinating because I remember when Sidekiq was first put out on the scene. It was like the premier tool to get error tracking inside of Rails apps as well. Fascinating, because I believe he's bootstrapped that as a one person organization the entire time.

Victoria: He did, he did.

Brian: I think the challenge that I see, because I talk to a lot of founders here in the Bay Area and through this podcast, and I think there's like the adoption... Actually, I just had a conversation with Brandon Burns on another podcast, The Secret Sauce. He was talking about specifically early days Kubernetes, co creator Kubernetes is Brandon Burns. He was talking about how you see adoption and interest and how you notice if you're actually doing a great job.

I think a lot of folks centralize around stars because stars is the easiest way to show interest. But the thing that they did at Kubernetes was issues was the thing they tracked. If the issues were up, as far as new issues, not open issues, but new issues being opened shows there's an interest in the thing you're working on. Then the thing that they even centralized around was that conversion to PR.

So PRs shows that people are invested, so you're using this thing and you see something is wrong, you're invested to go either build a fix or at least attempt building a fix. They hyper focused on that conversion of issues to PRs because a lot of people, actually, will open an issues no problem but very few people will cross the chasm to open a PR.

That becomes like if you're looking for your early adopters, fan groups, that PR contributor becomes that place that you can centralize on, "Okay, we might have something. We can have customer research, conversations, just from people who interact with just PRs." It's something that I think a lot okay folks dismiss because a lot of times you just get stuck in the star world or the twilight, but instead sometimes it's good to talk to people.

What I imagine with the way building sustainable open source, and honestly I frankly agree, setting up a proper entity around open source helps drive more adoption and interest. But also helps you accelerate into if this thing is going to fall flat, you're going to find out pretty quickly if there's an opportunity to scale this thing and make it useful.

I think in the world that I come from, now I'm in the frontend JavaScript world, things move very fast and folks, they see an issue and they want to jump on it. That becomes this question of how do you innovate and keep interest long term.

Victoria: There are a couple of things that are specific to commercial open source and developer tools in general I would say, as an industry. The first one about commercial open source specifically I guess is the setup allows you to get very fast feedback loops. You are able to close that feedback loop pretty fast because you get those PRs, you get those issues and basically your customers are able to speak with you through their requests, through their code so you know what people need.

The other thing is open source communities and developer communities in general are pretty vocal, but the downside of it is they're vocal about negatives more than the positives because when something is working you don't tend to go on the internet and just scream and shout about how well it works.

Sometimes you do, but most of the times you do so when you're unhappy about something, right? So that's a tricky part, but you also get feedback quickly which is great so you're able to act on those issues quickly and iterate and update or whatever.

Brian: Yeah. The fascinating part about the current state of open source and dev tools, you see more and more companies choose to go open source first and I heard that... actually the conversations around all these LLMs. So Open AI is closed source, open source first, now it's closed, perhaps might be opened. I think there are rumors they'll open source the older versions of the LLM and then closed source the stuff they're still working on, but who knows?

We're still waiting to hear back from Sam on that. But then Facebook or Meta just released the LLaMa version two which is open source, which it's fascinating. But the conversation around there in like Hacker News was like if you have a moat then you close source, but if you're catching up then you open source. I'd be curious on that last statement, do you find that true with the dev tools space around open source?

Victoria: I don't know. It's questionable. Not sure if I agree. To me, open source is something different. It's not because you're catching up. That's why you're opening your drawers. But it's because you're so proud of the quality of code that you're putting out there that you have nothing to hide. You use best practices and you are able... You literally have nothing to hide.

You are able to show the insides of your product and you're not afraid that somebody is going to take advantage of that because the reason why you created that product in the first place is because you're ahead in a way. So I really believe in collaboration and I think that one of the advantages of open source is that together we can move progress forward much faster because it's out in the open and you can, with your creativity, add something new to it.

So I'm kind of like really inspired by open source and I am much optimistic about it.

Brian: Yeah. We'll see where the cards fall, at least for this Large Language Model stuff. The notion of open source, because I think the reservation for a lot of folks to even choose open source because this is a conversation that just recently I saw an interview with Zach Holman with the Crowd.dev folks. Zach was an early employ at GitHub, and the question that even when I was at GitHub was why doesn't GitHub just open source GitHub?

That conversation, it was interesting to see that internally. A lot of that is behind closed doors, private conversation. But the context there is, yeah, GitHub would love to open source but at that point they'd really crossed a chasm. There's a lot of conversation, a lot of nuance in the GitHub issues, which actually someone throw a comment and tweet at me if I'm wrong on this because I could've crossed wires.

But basically it wasn't about the code, it was about the conversations that lead up to the code so to keep everything above board... Early GitHub had tons of challenges, but think of all those conversations at early GitHub, talking about competitors, talking about the insights in how they build their codebase. It was more about do you want to expose and let everyone in the house to see the historical record of 15 years of contributions?

On the inverse of that, if you look at GitLab, open from the start, you don't have to worry about anything because when everyone is watching you're always on your best behavior. For the most part. I bring that up because open sourcing a code is less the interesting part, unless you're looking to gift the thing to the committee. Execution is the thing that folks really see success from.

Now we have everything is exposed, we all can see how AI is working. Now it's about execution, so how do you get adoption? How do you grow community? Because I wanted to touch on that last statement about community and developer tools and the importance of that. What have you seen from the conversations you're having?

Victoria: Yeah. It's actually really interesting. You know the term open source was introduced in something like 1998? It's not even that old. If you think about it, we're seeing an industry mature right in front of our eyes. We've seen the first projects emerge just a couple of decades ago, and now we're just seeing them reach a certain maturity at this stage.

So I think there is an interesting time that we live now, after the pandemic happened a lot of people went remote and so suddenly there was this surge for developer tools and professional tools in general. Since we're all home, we spent all of our time at the screen, working on those professional tools, and all the mishaps suddenly became visible.

There was this surge of competition amongst different tools that everybody is trying to out compete each other because there is demand. Now we're hit with this market turbulence in the past year which is a fact of how people are raising rounds, et cetera. So we see those panels switch right in front of our eyes, right as the industry is maturing so it's really hard to say what's the actual predicament for the industry of developer tools or commercial open source.

But what we can say is that right now is a very opportunistic time because it's very cheap to actually start projects and to test your hypothesis. You don't need anything, you just need to run an open source project or to start to launch a landing page. You can already get your sales. You need Twitter and maybe LinkedIn to do it. At the same time, I think it's tough because there is... well, as I've mentioned, market turbulence.

So it's not clear how easy it's going to be to raise. Perhaps the same project would've raised a crazy amount of money five or seven years ago, right now it's not as feasible probably. So you can generate a lot of ideas, you can test hypothesis quickly, but how quickly are you going to get to a seed round or Series A is a very tricky question.

But also as we see the market mature, I think that we can see examples like Sidekiq where companies were bootstrapped and they work just fine. I think that there is a lot of opportunity for people to bootstrap, to test hypothesis, and if there is a market fit then there is an opportunity to raise as well. So I think it's a great time for developer tools and commercial open source projects.

Brian: Yeah. I'd agree too as well because I think what we're seeing right now, even with the current state of the market on a commercial side, is if you're interested in working on this problem and solving it and you can produce longevity into approaching this problem, regardless of market conditions, then you'll be okay. One of my mentors actually had mentioned just a simple statement on how to build a really good company which is, one, build a really good company and then, two, tell people about it.

I think the second half when it comes to open source, a lot of times we put things out there, we expect the things to organically grow adoption through just good will of people's interest. But I think the things that I always push through for the products that I engage with or mentor is guides, intro, documentation, simple marketing of how do I use this thing and how can I be successful if I install this package or library or Ruby Gem?

If that is clear, then usually adoption can come pretty quickly as long as it's a clear value proposition. I think a lot of times I see a lot of trending projects that show up on a Reddit or a Hacker News or even trending for GitHub, and it usually misses a lot of those marks because it's so new, it wasn't really expected it would take off. I guess luck is for the folks who are prepared, and I think a lot of times folks who have a little bit extra preparation tend to see things go off on trending to the right.

Victoria: For sure, and there are some things that can help you with technical projects in products for engineers. I do Dev Propulsion Labs, it's my series of round tables with industry leaders in developer tool space. What we talk about is how to create successful developer tools companies, and there's some characteristics that are very unique to developer tools.

So far we've covered four, one of which is developer relations, building communities around product basically. Second is technical marketing, and I want to stop here because technical marketing is so important. It's probably the most important thing you can do for your business, for your technical business and here's why. Basically, engineers, developers, is a tough crowd to sell. They don't buy into your average marketing, cold emails, et cetera. No.

They need to be inspired, they need to be solving problems, they need to have great tools to do their job. So if you're trying to market your product, the worst thing you can do is to just bland marketing campaigns with cold emails or whatever. The best thing you can do is to write articles about how to use your product, show videos how people use your product to solve particular problems.

Right now there is a surge of really authentic voice in technical marketing like Superbase is doing that, they're doing memes that are very much well received by the audience. But basically what you're trying to do through technical marketing, technical marketing meaning articles and videos and content that is saturated with value that sheds light on how your product can solve problems, how your product is used, what your product is for. That type of thing.

So generating value for your users through content is the best thing you can do, and if you inspire them, if you show them the path, if you encourage them to try new things, new ideas, show the new horizons to them through your product, then they're going to adopt it and, more than that, they will become champions in their communities. They will talk about it because they're happy to use a great product, so that's that.

The third part about developer tools is developer experience. By developer experience I mean product design for developer tools. When we talk about overloaded interfaces, professional tools that people spend hours and hours on, that user experience has to be very well crafted. It has to be empathic, it has to be encouraging and product design for developer tools is a very specific kind of science.

Those are the aspects of writing successful developer tools. One of the topics that I haven't covered yet, but I believe that it has tremendous importance is documentation. The way your documentation is done, the way it's written, the way it's proposed to users is extremely important. As you mentioned, sometimes engineers don't... Documentation is the only way for them to communicate with the product, so think of it as your cost savings on support.

If your documentation is done right, you don't need to spend that much money on support because it's just not needed. Self explanatory, empathic documentation is a must.

Brian: I 100% agree. Yeah, so I want to wind us down to picks, but I wanted to thank you for the conversation. I imagine folks, we have a lot of maintainers and startup founders and future founders who listen, so for folks who want to find out more of this information and more of making this jump from open source maintainer to startup founder or vice versa, where can they find more information about this?

Victoria: You can go to EvilMartians.com and shoot us a note. I'm the one who processes all the inbox emails so I will be sure to respond. We're also on Twitter at @EvilMartians so you can shoot us a DM there and I'll pick it up. You can also find my profiles on LinkedIn, Twitter.

Brian: Yeah. We'll add it to the show notes and then that way folks can go there on Heavybit and, yeah, check out this podcast. If you're listening to this in your feed, FYI we've got show notes on Heavybit so find Jamstack Radio and you can actually see the transcript as well as long as the stuff that's mentioned in the podcast. Cool. So let's transition to picks, these are jam picks, things that we're jamming on, keeping us going.

Could be music, food, education, tech related, all of the above is above board. If you don't mind, Victoria, I'll go first. I've got my first pick which is a blog post from Cassidy Williams. Cassidy, we've talked about developer experience and developer relations. Cassidy does a great job of building engaging content for audiences, the developer audience.

She wrote a blog post on Dev.two about Open Standards, it was a reflection post of what's happening with the Google Domains thing. Google Domains, if folks didn't realize, was purchased by Squarespace or announced to be purchased by Squarespace. There's not been any follow up on that, but it's got everyone concerned because Google Domains was the premier way for at least startup founders and folks who had a URL you wanted to attach to a Google Workspace... the experience of that was just great.

Still great today. It's all up in the air and the reflection was around Google Reader and how the open standard was RSS. Because Google Reader left us 10 years ago, it did not mean that RSS disappeared, including this podcast is built on RSS, so the open standard is RSS, everyone knows RSS is a thing to do to host your podcast, to send your blog through.

So the push, the ask for the community is more open standards which ironically Spotify has a new standard for podcasts which I don't know if a lot of people know about this. Spotify stopped doing that, we need to continue the open standard to make it consistent across the board. So that was one pick. I imagine you have some context around open standards.

Sorry, she also linked to open standards versus open source, that explanation. Open source is a little different. Another context is JSON, JSON is an open standard and that spec is open sourced, but the idea is that everyone adheres to sending APIs with JSON.

Victoria: So mine is completely irrelevant to technology. I have a personal pick this week. My mum turned 50 this year, and she just turned 50 like two days ago. Unfortunately I'm not near her to celebrate her birthday but I just wanted to shout out my mum because she ran her first triathlon this year, and I think that it's pretty badass to do that when you turn 50.

She also graduated university this year, so she got her first Bachelor's Degree. I mean, she's a professional in the healthcare system so I just want to encourage women and girls all over the world to think about opportunities, some things that you're afraid to do are not that scary and there is nothing that's stopping you so just go ahead and do it. That's my little pick.

Brian: Excellent. Yeah. Appreciate that. Shout out to mom and moms everywhere, as well. It's a hard job and when you find other jobs to do alongside of being a mother, it's even doubly as awesome. Yeah, appreciate sharing that. I did have one more pick which is #100DaysofOpenSource. At the time of this podcast release we'll be in the middle of it, but for the next 100 days we will be encouraging folks to do open source.

So if you use that hashtag on social, on Instagram threads and also Twitter, go ahead and check out the hashtag to see folks who are doing things in open source. The idea is you don't need to ship code every day, but if you read docs, if you build a tool with a project, share it and talk about it for 100 days. We start that July 24th, which will be way before this podcast releases, but check out the hashtag when you hear this podcast.

With that, keep spreading the jam