We chat with Ethan Batraski, who started his first web design firm at 13, lead product and engineering teams at Facebook, and now invests in open source software and developer tools as a venture capitalist at Venrock.
Ethan started his career when the marquee tag was king and is bullish on its comeback.
His focus as an investor is on developer tools & infrastructure, open source software, space, and emerging compute.
We talk about his time as a Product Group Leader at Facebook, and his strong feelings on the state of DevOps.
You can find his investor profile here, his blog here, and on Twitter here.
Our lifeboat badge of the week goes to Denys Vuika, who answered the question: How do I configure Yarn as the default package manager for Angular CLI?
Ethan Batraski The biggest pain point for me as mentoring leader has been this kind of like advent of the programmatic infrastructure like moving the controls away from DevOps and other non developer functions back to the developer as expressive and state code, that scalable that can adapt, that's gracefully failover. I don't want to be woken up at three o'clock in the morning anymore from a sad one because there's a misconfiguration in a YAML file because it pointed like a DB to the wrong location. Or like we've got the wrong version down, or an s3 bucket was left open or like, I can't tell you how many times I'd walk in like a data pipeline filter run because a server went down or an exception was found in the data set or a job took longer than expected or dependent tasks to stall, like my data engine DevOps teams like literally spent countless hours manually trying to figure out what happened, like these things should be happening in the 2020s.
[intro music]
Ben Popper Are you spending too much on cloud object storage? With Storj DCS, you'll save up to 80% while getting unparalleled security for your data, and every object is encrypted by default. Try it free storage.io. That's S T O R J .io.
BP Hello, everybody. Welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, the director of content here at Stack Overflow. And I am joined today by Ethan Petroski, who is a partner at Venrock, a venture capital investing firm and was formerly engineering Product Manager, leader director at Facebook. And with me, as is often the case is our wonderful collaborator Cassidy Williams, who is Director of Developer Experience at Netlify. Did I get that right? DDE?
Cassidy Williams Yep, that's right. Happy to be here.
BP Welcome, Cassidy. So Ethan, why don't we start out, yeah, tell us a little bit about like, how you got into the world of software, what it was like to work at Facebook, and what you worked on. And then we'll talk about sort of your role these days, where you do a lot of investing in software in the world of open source, which is what we love to talk about on this podcast.
EB Well, thank you for having me. And I'm super excited to be here with you guys. how I got into software started when I was nine, because my parents had made a computer camp against my best wishes and hopes because I think I probably want to go to basketball camp or something like that. But I mean, it was awesome, three o'clock in the morning, playing Red Alert against the counselor as well. And I actually became a developer at 13, I started a web development company. And just that's the way I ventured my way into startups, I had my first real startup job when I was 17. And just kind of lived through the crazy .com boom. Started as a developer ended up feeling like I had a pretty good product sent on it, being a product manager, and then from there, and leading product and engineering teams through my career. And so most recently, before Venrock, I was at Facebook, I ran the product and engineering team for one of the ads teams, and we ran a $15 billion dollar business, looking over after the performance as a business and it was a wild ride. And then I found my way into Venrock. While in operator, we actually started a pre seed fund called Profounder. We ran that for five years. And you know, that was a venture model that we put together with, it was 11 of us were all ex-founders active operators. And we were hoping to design the venture process in the way that we wish we had it when we were first raising money, I started my first startup, when I dropped out of college when I was 22. You know, most investors, at that time come from a financial background or investment banking and didn't really have experience being an operator, sitting in those shoes, knowing what to do when shit hits the fan. And we want to design the process in a way that you felt like you had an extended team and that, you know, naturally every startup team is incomplete. And how do we help you think about how to get to product market fit and how to scale and who to hire first? And how do you build going to market into your product requirement? And so we focus a lot on just like really digging in with the teams and just had the most amazing experience. And if I might, myself thinking more about my companies and the interesting problems, they're going after across robotics and space and, and developer infrastructure than I was about, you know, the day to day of like, expanding an org dealing with, you know, strategy at the corporate level, you know, reviews and one on ones. And like, while it was an amazing journey, my mind was more optimized for solving six or seven different problems at once. And so that's what led me to Venrock. And I've been there for four years now.
BP So I guess yeah, like when you started a web development firm at 13. What did the landscape look like? What were customers coming to you and asking for? And if you can remember, what kind of tools Did you have at your disposal? I mean, well, yeah. Do you remember what you built for customers back then?
EB Totally, to date myself, let's say when I was 13, that was like 1987. So you probably had a website on Geocities or Zoom.
BP Different Zoom.
EB You definitely used, you probably used like HTML marquee, a lot to things could fly. And move across the page as you should, I was always hoping we'd bring that back. And you probably were using Adobe Dreamweaver, wow, this is really bringing me back. And my like edge was, I was a huge Dieter fan. I always loved Swiss design. So I thought, hey, I can make your web page a lot cleaner, and a lot more performant. Because remove all the crap. And then I would optimize, I guess it was like a very early version of JPEGs. back then. So you wouldn't, you know, back then like you'd use a JPEG your entire background, right? And I'll take like six minutes to load the page. And it was, it was awesome. The landscape was like, you know, Geocities, that was like your competition.
BP I kind of remember, yeah, backgrounds doing the crawl like they would load sort of like layer by layer for you.
EB Like when lazy loading was established. My mind was like [makes exploding noise]
BP Was Adobe Dreamweaver a good tool? Like maybe it was a tool of its time. But was it a good tool? Or was it frustrating to work with?
EB I thought it was a great tool. I mean, I was a fan of the of the WYSIWYG approach, but the ability to actually get into the HTML and not really using CSS back then give you like, ultimate flexibility yet you didn't, you just had like, rapid refresh. And I think, at some point, we lost that ability to have that kind of rapid refresh. And as we develop, as we have to, you know, push into our CI/CD pipeline, and wait seven minutes until I can see what it looks like and make sure it passes, tests. But I thought it was great, you know, for what you can do back then.
CW Oh, yes, the wonderful world of web 1.0. I remember being able to just play around with Internet Explorer seven, and the power of transparent PNGs. And just messing with HTML and CSS based on viewing the source of the website.
BP So yeah, we're gonna get, like I said, to sort of your investment thesis and your thoughts these days on open source software, but just to pass through a little bit more, can you tell us and for the folks who are listening, who are often interested in this kind of questions, when you were an engineering lead at Facebook, what kind of advice would you give to people who are joining the team? Like what, what kind of advice would you give to a junior, you know, during the team, like, these are some things we think you should or shouldn't do, these are kind of the best practices. This is how you can get the most out of your experience here and help us you know, craft great software.
EB Facebook is a massive behemoth. At the time, we were six or 7000 people. And that was massive. And today, you know the product, you know, 6000, I guess felt small, but there's probably like, you know, 700, 800 teams. And probably up to half the time, a fifth of the company just focused on infrastructure to support developers, like everything from how you deploy to how you run an A B test or a bucket to what are the API's available. And so it was a dramatically different way of thinking of approaching how to build, because you didn't have to think about endpoints and how to secure the endpoint. And then what the SLA on the endpoint was because I was someone else's problem. Like you had to focus on how to leverage it and how to make it make it as performant as possible, literally with the least amount of lines of code as possible, and then how to make it in a way that users love. And so there was a few pieces of I think, eye opening moments that we helped early engineers think through and focus on the product side as well. One is in the first six, eight weeks, just listen, just listen, watch, Learn. Facebook has a tremendous boot camp program that gives you a kind of the broad swath of all the tools and capabilities and it's very overwhelming. So just play around. And don't worry about having to check in code right away and contribute like this is about long term investment, I think to think about people problems, think about the users and solve important user problems, and then work your way backwards from there. And then three, was always trying to simplify. It's very easy to over engineer and especially when you give someone more time than they actually need to solve something. We tend to keep adding and keep building and through—
BP Bells and whistles.
EB Right. And we were just trying to and we were trying to do the opposite, like strip it down to the most primitive requirements and just meet the set of guiding principles and orders what the definition of done was and move on. And the saying of like break things, move fast. Like it's not just a marketing byline. It's just how we operate and it allows us to move super fast and yeah, there's some some things were janky at the edges, but that was okay.
BP Cassidy how does that square with some of your experiences working in the industry?
CW Varies depending on the company you go for where some companies I've been at, they're just like, we love the concept of move fast, break things. How about move fast and write tests instead? I think people all try to do their own variations of this, but Facebook was definitely a pioneer in a lot of these practices.
BP Yeah, that's a fun game. Now people like to say move fast and and then they put one on you but the original, all pay limitations in the original. So yeah, let's dive a little bit into what you do now. I guess, you know, from your bio sounds like you invest in software and outer space. We'll leave outer space aside for today. I'm sure it is super interesting for the purpose of this podcast. Tell us a little bit about, yeah, like, when you came to Venrock, did you know that's the space you wanted to play in? Sorry, I said space. Did you know that was the sort of like industry an area you wanted to focus on? Or did that develop over time? And yeah, like kind of, what's your broader investment thesis? Like, what do you think about when you look at companies in the software space and decide that, you know, you think they'll be worth or be very big companies, you know, 10, 20 years from now?
EB Yeah, yeah. So to give kind of some context and background for the listeners, so venrock has been around since the 1960s. We were one of the earliest venture funds, originally from the Rockefeller family. Really, with a mandate to go back the kind of force in nature founders that go change the world across biotech. And so we were privileged to be some of the first investors in Apple and Intel and Illumina and CloudFlare, and Kellyanne and others. And we're fortunate to be able to continue that tradition to this day. So today, we invest across sectors, with developer tools, infrastructure to kind of along franchise as far as the CloudFlare, and chip security, nyrA, and others. And so kind of long focused on developer infra, particularly at the kind of platform and data layer, kind of as the stack of views become more complex with that proliferation of Kubernetes and micro services and multi hybrid cloud and streaming data. And now we have hybrid data, Lake houses, you want to be able to, yeah, I sometimes I don't know what that means. You want to be able to build in a weekend, but scale to millions of views. But up until now, that's really required significant people resources, right, huge alliances on DevOps and SREs and sec ops. So we saw the massive opportunity and kind of what I've been kind of the biggest pain point for me as mentoring leader has been this kind of like advent of the programmatic infrastructure, like moving the controls away from DevOps and other non developer functions back to the developer as expressive and state code, that scalable, that can adapt, that can gracefully failover, I don't want to be woken up at three o'clock in the morning anymore from a sad one because there's a misconfiguration in a YAML file, because it pointed like a DB to the wrong location. Or like we've got the wrong version down, or an s3 bucket was left open, or like, I can't tell you how many times I'd walk in like a data pipeline failed to run because a server went down or an exception was found in the data set or a job took longer than expected or dependent tasks to stall, like my data engine setup teams, like literally spent countless hours manually trying to figure out what happened, like distinction be happening in the 2020s.
CW I agree completely. And I personally am really excited about the developer tool space as well, just being able to kind of decouple a lot of these things away from the core part of your product, so you can focus on that. And then when things go down and stuff, your website should still be able to generally run and not everything go down all at once.
BP And so I guess you know, one of the things we've talked about a lot on this podcast, yeah, it's kind of there are these waves, there's almost like this pendulum swing that takes you from more tooling and complexity, like you said that offloads work you're doing back towards, you know, sort of a sense of like, more like you said, sort of fine grained control. So you want to move us like in a direction away for the time being from some of the almost like, over architected things that can leave you with a lot of like you said, complexity and dependencies that would be your thesis for where things need to go in the near future or the far future?
EB Yeah, I think it's the way I think about it is it's a shift away from static config files and YAML files, and cron jobs and things that are fixed and unresponsive to things that are in code and dynamic and adaptive. And I think that also just has this change, abstracting out the myriad of complexities that we deal with today. But also it changes the roles of what an SRT and DevOps should do and what a developer should do. To me that DevOps is this concept that originally started as really a concept of right, how do you bake in operations into the developer workflow, and then somehow, it morphed into a role itself, and then it morphed into, like, fiefdoms. And that created silos, and then that created tools for those silos, and that just kind of like proliferated the problem.
BP Yeah, that makes a lot of sense. I do think that as it became sort of a buzzword and a best practice, and a lot of what I've been, you know, reading in the world of sort of like, oh, gosh, I don't know, you want to call it thought leadership and marketing over the last couple of years, you know, right. You know, you're pitching the concept of DevOps to a larger enterprise that in its DNA is going to then take that out and make it into its own department with its own class of middle managers. And so it yeah, it kind of gets away from like, you're saying the original spirit of it, which was to sort of combine the two things tighter together. But certainly, yeah, I mean, like this point, you can go get like a master's degree in DevOps. I mean, like the, you know, the career has become well defined as like a track with a number of different you know, certifications or qualifications, you could add to it.
EB Totally. I've written a number of articles on the death of DevOps and, most often DevOps, don't return my call anymore. Still, I still love you guys. It's just the role needs to change and it needs to be less about firefighting, less about keeping the lights on and more about creating more automation and Enabling more tools to increase developer productivity and increase resiliency. And you know, I like I love the Netflix approach of chaos engineering. And, you know, DevOps can be leading that kind of concept.
CW Yeah, I think they're definitely still necessary. And so that's probably why they're just yelling at you in your inbox. But it does need to change. And the world needs to shift away from needing to rely on a DevOps person to make sure the website stays alive, it should be something that is split up across teams where they can focus on, like you said, optimizing and automation and all of the things that can make the rest of the team more productive.
BP But somebody has to write, you know, the SREs the one who I will be on pager duty, you know, like they accept that role and the power that comes with it, right.
EB And that's interesting point, because that's also introducing a new paradigm and how some software or some infrastructure is being deployed and bought. Right, now we're seeing the kind of proliferation of managed services where the control plane is a SaaS service, but the execution happens within your VPC or within your environment. And the service itself is offering kind of the SRE portion and the DevOps portion right there. They're maintaining uptime, and responsiveness and scale. And now you can deploy airflow, for example, at scale without having to add six more DevOps, two more data engineers and three more CSRS as you continue to scale the deployment. So I think that starts to become more a norm.
BP And it works most of the time. I think today, like 12 of the largest corporations and banks are offline for a little while, I'm sure we'll figure out within 12 hours. Why, but yeah, well, there was a piece up on the Stack Overflow blog today that I think gets back to something you said earlier, which is like, why it makes sense to use Kubernetes, even from the beginning. And a lot of it was kind of what you were saying, which is that as this stuff gets easier, and as more of it gets outsourced, you know, away to a cloud provider who's going to help you spin up a container, you can then have this ability from the beginning to scale very easily, you know, if you happen to hit that sort of exponential point, which is a big advantage down the road. So if the overhead left at the beginning isn't so hard, because you're offloading to these managed services, then you in the end, you know, you might end up with a lot of big overhead benefits, and less, I'm gonna call it technical debt, but you know, like a form of technical debt, which is like having to rewrite for scale.
EB Totally right. And it is a double edged sword, because on one end, it allows you this massive scale and simplification, but at the same time, it creates this new set of complexity, because Kubernetes is not exactly a easy piece of software to run and use. And when I pull, you know, if I pull 100 engineers, I think probably 20 will say, yes, I feel like very proficient and the other 80 were like, I kind of know how to deploy a Docker image and run it. But I'm not really sure thing else like whether all the bells and whistles and when I look at the YAML file to configure, like, what are all these things that I can do? And how much memory should my machine have, and, you know, the list goes on. So I think there's a lot of room to solve that, like the Heroku esque approach. But for Kubernetes.
BP The other thing I wanted to mention was, yeah, you had written a bunch of pieces about sort of commercial open source software, by the time this episode comes out, Stack Overflow dev survey will come out soon. And as often as the case the sort of most one and most loved languages include Rust and Go and this year kotlin, which I don't think I've seen on the list before, but we're just sort of remarking that all of these are, you know, open in a certain sense, but also stewarded by a single, you know, like corporate organization and another is there some like through line between those three, you know about that says something about how to be how to do a good job is like the steward of an open language. So yeah, I just wanted to sort of get your big picture take and have Cassidy weigh in, like, where do you see the happy medium of commercial and open today? And do you think it's gonna be evolving? Like, is it gonna look very different in five or 10 years? Or have we kind of found the sweet spot? Because it certainly seems like a lot of big corporations that once fought tooth and nail against it are now giving it a big, you know, friendly bear hug?
EB Yeah, I think we're starting to see a happy medium evolve where the pendulum hasn't swung too far in any direction. To me, a successful commercial open source approach is, follows a few tenants. One is it makes the open core totally open. And it doesn't restrict usage. Maybe there's some like a common clause. So you prevent, you know, AWS from just like ripping it off and offering it as a service. But it's totally open. And there's a kind of clear set of principles between what's open and what's closed. And that set of principles are communicated out to the community. So it might be, you know, individuals, this open chords optimized for individuals, where teams, we have another set of capabilities like rpac, insert integrations and so on, where it's not an enterprise product, or it might be optimized for those that are pre revenue and what the requirements are for scale for post revenue, or it might be self hosted versus managed service. And so I think it really depends on the project itself, but I think having that clarity creates a lot of awareness. And it creates a better dialogue with the community about what goes into the open, versus what goes in the closed. So you don't get into the drama of like, you know, I have a new PR, but no, no, I want that in the closed roadmap. So I think that's one, I think two is I think there's always should be a graduation path or something that you deploy and into the kind of commercial product into the open, like whether it's a Kubernetes operator, or whether or discern a better UI, or you know, better who has better ability to horizontally scale like that should eventually always make it to the open, because you always want to continue to contribute to the open core, drive more compute community engagement and excitement and continue to push the project forward. So I think that's super critical. And I think the third one is making sure that you don't lose sight of the community like that. The reason why you that the reason why there's such a tailwind in commercial open source companies where they work is that you can take the spend that you otherwise would have spent on sales and marketing, to go acquire customers and move it to engineering by having a dedicated kind of open core team. And that spend is way more durable than you would spend otherwise on sales and marketing to generate new leads, because that means all the leads coming in on the commercial side are probably already decided they want to use the project or are using it and are struggling, because open source is built by the community for the community, right? It's not always enterprise ready, or they've deployed it internally. They're scaling it and now they don't want to add more headcount. And they need some more additional support and capabilities. And so that's this very durable flywheel that you can continue to invest into, all while building developer love and you know, community engagement. And that's just a really powerful model. And that's just very different than you know, just a commercial only kind of enterprise b2b company.
BP Cassidy from where you sit, yeah, what is the sweet spot? And is there a direction you hope it evolves in?
CW Yeah, and so I think the last point that you made Ethan is the biggest one, the community focus one, because so many times when I see open source driven companies start to fall off the roadmap, or of where tech is going, it's when they start to neglect their community. And it's when it's when they start to focus more on their bottom line and their teams and start to reject community PRs and, and community contributions and stuff. And so being able to foster that community, I think is so key for any of these companies to do well. I think in general, funding for open source is something that still needs to be fixed. It's a problem that there's some companies trying to solve it like open collective, and floss bank. And some of those, there's a lot of companies where they go with the sponsorship model of we'll sponsor this, this open source plan, but for every 1000s of users of let's just say React router, there's probably maybe 10 that donate to that project. I think that is the model that needs to change the most, because these open source companies, I think, can do so great. But funding open source in general is, I think, the biggest issue in open source these days.
BP That's really interesting. I mean, when I was listening to this, I was thinking a lot about sort of the old school copyright and something that you were talking about, which is that, you know, that should always be on the roadmap that even if you're going to commercialize this, you know, then at some point down the road, it's going to become public domain. And to keep those two things in balance the same way you would with like intellectual property. And I guess yeah, one of the things that strikes me is, if and when these open source things get commercialized, what is a great way to have trickled down is kind of a bad way of phrasing it. But to have some way of distributing you know, the rewards of whatever comes out of using those open source tools to build these big commercial ventures, whether that's licensing or some sort of participation that goes beyond right, tip your developer, buy me a cup of coffee, which, after a while, tends not to work.
CW I'll just add one last point there. I think it to Cassidy's point, like I think it's totally requires a shift in how the venture ecosystem thinks about open source. And it requires a rethink of the benchmarks that you expect at each stage, you think about funding. Like for us, we love funding open source projects that focus just on the community. And don't think about the commercial side yet. And understand that that means in the seed, you're focusing just on community, in the A, you might still be focusing just on community and growing the mean engagement and contributors and you know, some of the vanity metrics and at some point, you'll, you'll find the right sweet spot for the commercial with the commercial divide is and able to switch over, and that you could use that massive community in order to fuel and fund it. But you know, gone are the days of, you know, raising a series A and where you need a million of arr and 40 customers and so on and so on, like an open source that just doesn't exist. Unfortunately, there's a few of us that really understand that.
BP Yeah, no, that's only true for digital media companies. No more clicks and readers. They want to see some real money. Our poor compatriots in digital art.
[music]
BP Awesome. Well, Ethan, Cassidy, thanks to you both for coming on. It's been a fascinating discussion. And I'm sure, yeah, lots to unpack here for folks who are interested in building software or working in or investing in it. I will as we do at the end of every episode, shout out the winner of a lifeboat badge. Somebody who came on Stack Overflow and found a question with a score of negative three or less, gave an answer. And the question went up to a score of three or more. And that answer has a score of 20 or more. So to Denys Vuika, 'How do I configure Yarn as the default package manager for Angular CLI?', awarded July 18. Alright. Well, if you're curious about that, we'll have an answer for you in the show notes. We'll say our goodbyes. I am Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper, or you can always email us podcast@StackOverflow.com. And if you'd like to show, leave it a rating and review. Cassidy tell people who you are and where they can find you on the net.
CW I'm Cassidy Williams, Director of Developer Experience at Netlify. You can find me @cassidoo on most things.
BP Wonderful. And Ethan, tell people who you are, where they can find you on the internet. And yeah, if they have an idea about software open source, where they should reach out when it comes to Venrock.
EB I'm Ethan Batraski and my general partner at Venrock and you can reach me on most platforms at @EthanJB.
BP Awesome. Alright everybody, thanks for coming on. We'll talk to you soon.
[outro music]