We chat with Geoff Schmidt, CEO and co-founder of Apollo GraphQL, about the need modern web companies and mobile apps have to stitch together multiple databases and cloud services in a way that is simple to query. He talks about the foundation of these ideas with a previous venture, Meteor and how to balance a vibrant open source community with a for-profit SaaS company.
You can read about GraphQL here and Apollo here.
Cassidy Williams, who curates our newsletter, wrote about her experience as an early adopter of the technology last summer.
You can find more on Meteor here.
Schmidt also helped create Monument, which he describes as "an affordable live/work art event space in downtown San Francisco. The upstairs is 24 private bedrooms and studio spaces and the downstairs is a 200+ capacity person event venue and makerspace. Our goal is to connect creative people across different fields, and in particular build bridges between art and technology."
Geoff Schmidt If you look at how people did that in the past, you probably had some sort of tier in the middle. At least, if you had more than a couple teams, that act is almost like remixing those back-end API's and the front-end API's. And sometimes it's called a BFF tier, a back-end for front-end tier, sometimes it's called a product API. Sometimes it's called a, you know, gateway, you know--
Sara Chipps I've never heard of the BFF tier, but I'm all about the BFF. [Ben & Geoff & Sara laugh] Me and my BFFs, we make the tiers.
GS Yeah, and you better be BFFs with your BFF tier. [Geoff & Ben & Sara laugh] Every single screen in your app, you're gonna need something from them.
[INTRO MUSIC]
Ben Popper Couchbase is a modern, multi cloud to edge, SQL friendly, JSON document database for building applications with agility, performance, and scale. If you're new to Couchbase and would like to learn more, the Couchbase Developer Portal is the best place to start loaded with tutorials, videos and documentation, as well as best practice tips, quickstart guides and community resources, including the Couchbase Developer Community Forum. Ready to get started developing on Couchbase? Visit couchbase.com/newtocouchbase.
BP Hey, everybody, welcome back to the Stack Overflow podcast. It's December. We're here. Sara, how you doing today?
SC Good Ben, how are you? How's your day? It's a beautiful day out here in Florida. [Ben laughs]
BP My day could always be better, because I could always be in Florida with you, Sara. But we have a great guest today. Geoff Schmidt, CEO of Apollo GraphQL. Geoff, thanks for coming on! Why don't you introduce yourself?
GS Sure thing. I'm Geoff. I'm the CEO, one of the cofounders of Apollo GraphQL. So we make Apollo Client, which a lot of people use, it's a cool time for us, I think we just crossed the 2 million downloads a week mark for Apollo Client, our first 2 million download week. So it's been really fun seeing the growth over the past couple years really, I guess, since we first released it in 2016. And all the cool stuff that's happened in the GraphQL community. Yeah, it's really exciting to be on the show. Thanks for having me.
SC So GraphQL. Obviously, I we have a I have a great dashboard, where I can see the tags and how quickly they're growing on Stack Overflow. And GraphQL is definitely been taking off like a rocket this past year. So what does Apollo bring to GraphQL?
GS We built a lot of open source tools that are probably used by many, if not most of the people somewhere in their stack. So there's Apollo Client, which is a great way to consume a GraphQL API, whether you're doing that with react, or Angular, or viewJS on the web, there's also version it for iOS, there's a version of it for Android. There's Apollo server, which is a great way to take the existing API's and data sources you already have. And very quickly build a graph on top of that. So that answers the question, ''Hey, I've got a whole bunch of existing stuff. Maybe my back end team isn't going to implement graphQL. For me, that's the usual case, how do I as a product engineer, be able to quickly get all that stuff onto the graph?'' And that's a good place to get started. And then we have some great tools like Apollo Explorer, how do I compose queries, browse my graph, you know, view all that the resources available to me. All the way into, you know, as you start to go into production, you want some good analytics and monitoring on your graph. We have a commercial SAS tool, Apollo studio to help with that. And then when you start asking, how do we go from one team to many teams on the graph, how do I build an enterprise scale graph, you start to want what we call a graph router, a way to sort of take a graphical query and break it up into multiple teams, we have Apollo Gateway for that, and, you know, whole set of technologies help you manage multi team enterprise scale graph, and all the stuff that goes into that. So you add all that up, it's pretty much a full stack data graph platform, that lets you take all of your existing data sources and services and query them all in a unified way with graphQL, for a pretty cool, integrated experience. And of course, it's all graphQL standards compliant, so you can mix and match it with all the other stuff in the graphical ecosystem, if you want to use something like graphQL Java, or if you even want to consume the API's just directly through like, just like hitting a REST endpoint, you know, there's a lot of flexibility to kind of pick and mix the components, you know, to build your graphQL solution.
SC That's great. That's really fascinating. One thing that you said that I'd love to dive into is, you see product engineers that want to use graphQL, but their back-end team isn't building it in. So they're using it anyway. So are they, in that case, are they just building a layer on top of an existing API using graphQL?
GS Yeah, you know, the way I think about it is this, that layer probably already exists. And this is more about how we rethink the relationship between those micro services or whatever those back end resources are. And then the consumers of that, because if you think about it, if you're building back end services, you probably think about them in a really modular or even orthogonal, find one of us a big fancy word kind of way. I maybe got my product service and my inventory service or my news feed story service and my comment service, I might put all those in different tables or services, or however I model it, they might even be maintained by different teams. They might be written in different languages, we might have more or less of them. And it's really good if those things are modular and do one thing well and solve one kind of business concern. But then if you think about how we build applications, in the applicantion, we kind of slice it a different way. Any given screen in an app, and a given web page probably contains data for multiple services. So the challenge we have is, we have one set of API's that are these sort of very modular, you know, separated API's, which is how the services team probably thinks. But then as product engineers, we need to combine that data to build these solutions or user experiences. So if you look at how people did that in the past, you probably had some sort of tier in the middle. At least, if you had more than a couple teams, that act is almost like remixing those back-end API's and the front-end API's. And sometimes it's called a BFF tier, a back-end for front-end tier, sometimes it's called a product API. Sometimes it's called a, you know, gateway, you know--
SC I've never heard of the BFF tier, but I'm all about the BFF. [Ben & Geoff & Sara laugh] Me and my BFFs, we make the tiers.
GS Yeah, and you better be BFFs with your BFF tier. [Geoff & Ben & Sara laugh] Every single screen in your app, you're gonna need something from them. So and it just gets, in the public that BFF is it gets to be a monolith, you end up with so much code in that thing, so many people touching it. The question becomes, how do we how do we just make that go little faster? build a better experience for everybody?
SC So are you saying that in this, so like pretend scenario, I work at Realtor.com or some like huge monolith application, I'm guessing, I don't know, Realtor.com, I'm just guessing. They could have a really agile really microservices based application. But so I'm working there, I have a team of six engineers, and we particularly work on the cards for houses, and our data structure is spread across several different platform engineering teams. So in this case, if my team wants to use Apollo tools, I don't need to get buy in from the entire company, we can just use it as a way we manage our services from our team.
GS Absolutely correct. You know, that was something and we've been building graphQL tooling since 2016, and talking with many different people about what their adoption pattern has been. And for Apollo, I like to think about our mission is we want to help app developers help the world, we just believe that app developers, you know, apps are the point of value creation, like we create all this--we've got all these transistors and operating systems and CPUs and such all that becomes valuable. Ultimately, when we can put pixels on a screen make something that people can really use in touch. So that's really sort of our fascination or obsession is how we enable app developers and product engineers. So we really talked with all the people that were adopting graphQL. And we've said, what's worked and what hasn't in different organizations. And then we really designed Apollo around that. And so what we heard is, you know, it should be very easy for a product team to adopt. So that's the whole idea of Apollo server, you can very quickly, you know, just with a few lines of JavaScript, you can kind of block out your schema, you can say, ''Hey, I've got customers that first names and last names, I've got houses, they have addresses, they have GPS coordinates, I've got, you know, all the other sort of domain objects that exist in Realtor.com.'' And then you can just write a couple lines of code, with the Apollo server, if you choose Apollo server for this couple lines of JavaScript, to map those fields on those objects back to different API's or data sources. And then once you've got that, you know, you can, that's a nodeJS process. And you can deploy that as your mapping layer, from those existing services to a graph. And you can usually get into production with that pretty quickly. And it just kind of prove out the graph feels valuable. And that just reduces the number of moving pieces you have. And it's a really magical experience, to see how little work you have to do. And it is some work, I'm not gonna lie. And now you can like type these graphQL queries into something like Apollo Explorer or graphQL playground, and like, see your date and all these different joins and forums. And that's a great way to sort of bring graphQL in to your team and let everybody kind of see and touch it and feel it and see the see if it's valuable, and see if it works for you. And then often after that, you know, there starts to be some more conversations, more teams, you know, they might want to get involved in different ways. Maybe they want to add some graphQL support to your existing, you know, Ruby on Rails back end or existing Java back end, or there's a lot of reasons why, you know, as you build out your architecture, you might get more teams involved. But yeah, it's really designed from the ground up to be incrementally adopted, and to make it very easy for product teams to be able to get in there and get it up and running.
SC It seems to me that we've kind of gone, and I've been thinking about this a lot. I'd love to get your thoughts on it. It seems like we've gone from monolith applications to micro services and that the thing that microservices has done is created a need to normalize the data going to micro services, it's like everything got there was like a sprawl of the data and with platforms like graphQL and yours The idea is to reduce that sprawl and make it more accessible for the rest of the people using that layer. What do you think about that?
GS I think that's absolutely right. And I think it's just driven by, we're doing more and more stuff with computers, we're doing more and more stuff on the internet. And I think the other pattern we're seeing is, it may not only be services and resources, you know, inside your company, you might be pulling in data from other SAS services, increasingly, or other business units. It's like, if you think about everything that goes into an app, it's just not going to be scalable or sustainable to have one team builds the whole back end. Or maybe even to have one company, build the whole back end. We've gone from a world where it was a web server talking to a database, to really this whole like ecosystem of stuff that we're mixing together to build an app. But that's also true on the other side, we used to have a pretty simple sort of way we were delivering this, like we delivered into a web browser with HTML and CSS. And that was good enough. And then we added mobile devices. And people started to struggle with how do I keep feature parity between my web team and my mobile team, I'm reimplementing a ton of stuff multiple times on each platform, and each platform is a little different and tougher to combine up. And now we see more and more people want to explore this whole world of IoT devices or like new platforms that are showing up every time or they want to embed their functionality inside, you know, other people's websites or apps. So it's just turning into more of a many to many ecosystem, rather than a one to one ecosystem is the way I think about it. Because it's not like a single thing we built, those things now exist in this larger ecosystem. So sometimes they say, like, rest API's, it's a very point to point way of thinking about things because it's based on these endpoints. It's like, if I want one thing to talk to another thing, I build an endpoint, I wire that up. And I think the data graph is kind of, it's more like a dial tone. It's like, I've got a phone book of all the stuff in the cloud. And I can dial up anything I want. And I can conference call together anything I want. Like, if I'm building a banking application, I want to show all you show you all your finances on one screen, I can kind of dial up the customer file, I can dial up the checking account service, I can dial up the mortgage service and get the balance of your mortgage, I can tie up the investment service and I can almost conference call all that together to get a complete view of you know, your stuff, I can do that on one round trip, I can do that all in one query. And it's almost like doing for the cloud, for cloud services, what SQL did for the database, because before SQL, you know, you had to write all the code to go fetch the fetch the stuff from wherever it was, and join that together. And it's saying, hey, we want that same abstract declarative way, that same abstraction layer, between our apps and our back end, it has this kind of declarative query functionality. So we don't have that tight coupling anymore. That gives us more flexibility as things get more complicated.
BP It's interesting, you mentioned that I've seen a few services recently that offer the ability to pull in all of your different financial data from like six or seven providers, and then sort of scan that and you know, display it for you with a new set of analytics. And I actually remember thinking, how is this possible? There's so many security hiccups, and, you know, so much, you know, regulation around all of this. So, in a modern, you know, yeah, mobile app, now you do have the ability to play nicely with a bunch of different data sources, which is fascinating. So let me ask you a question. Maybe we could do a little bit of history, sort of where you got started, I saw some pretty fun stuff on your LinkedIn. I think this says: ''Artificial intelligence research consultant. As a punky dropout kid in Cambridge Mass. I studied Zen Buddhism, went to Burning Man and tried to figure out how to radically decentralized the internet.'' I'm going to stop there.
SC Isn't it always your dream to have someone read your LinkedIn to you? [Sara & Geoff laugh]
BP I don't see a lot. I don't see a lot of LinkedIn's that start with that. I thought that was pretty bold. Tell us a little bit about where your roots, you know, where you came from, before you got into the position you're in now?
GS Sure. I've had I've had quite a path. So I grew up in rural Missouri, in Arkansas, you know, I just got fascinated with computers. There weren't that many people that I could learn from that I've taught myself and I entered the, you know, one of the one of the things to do in Arkansas was to enter the science fair competition. So I was that was a place where I could I worked on different, like, I worked on some computational geometry problems. And I worked on some data compression stuff. And I won a lot of like, kid awards, like, to the point that they flew me to the Nobel Prize ceremony to sit at the kids table and be the table ornament, right? [Geoff laughs] And based on that, I thought it was too cool for school and dropped out of MIT after turban started a company called to print which was one of the first audio fingerprinting companies. So the same type of technology, it's in something like Shazam, right? That was my first experience with venture funding. And so I learned a lot about running a business that kind of a young age, and then after that, I wanted to just kind of, maybe catch up on all the college stuff that I had done and like learn how to be a human being not just a coder, and yeah, so this was, I guess, the early 2000s before AI was really the kind of thing it is right now. But I had some AI consulting jobs that I use to pay the bills. And yes, that was, you know, the time in my life that I discovered Zen Buddhism. I'm the first generation of my father's family to not grow up on a Mennonite farm. So that is kind of maybe set me on a track of learning more about the different ways people see the world. Yeah, and I guess the other thing that's relevant, I worked on a lot of different, you know, some stuff that was totally open source and grant founded and some stuff that was like various, like seed stage startup funding stuff that was all with this goal of like, how can we use the internet to, in some way, that'll be a force for human good. Like, we've created this amazing technology, it can connect so many people, how much thought we really put into how we bring that back to human well being and human connection. And in my 20s, I was really focused on kind of what I saw as the toxic or corrosive effects of centralized power structures. And I thought, maybe if we put the technology in people's hands, like that'll solve the problem, and I think what I came to learn is, you know, you really need to engage with the full kind of spectrum of the humanities to understand how society is going to work, like one person isn't going to have the answer. And it's not just technology we need.
SC How old do you think you are when you realize that? Well, I'll say this, I feel like our field attracts a lot of people with the initial mindset of ''If we can just empower people by giving the things that we need, then everything's gonna be fine.'' Right? Like, that's, that's, that's the challenge that we need to solve. And then I feel like there's a point where you realize this is actually a very dimensional problem. And I, I am one person, and I can't understand that. I think some people realize that some people that don't. But yeah, is that an age thing? Or an experience thing? What do you think made you come to that conclusion?
GS Well, I think being in a CEO role, where you really have to spend all of your time thinking about the well being of your team, and the experiences people are having at your company, and the well being of your customers and the well being of the community in the ecosystem. I think that's something that, you know, helps you see the larger perspective. I also think that some of its about history. You know, I remember, I moved to San Francisco at the end of 2006. And tech start for this totally discredited idea. We tried that in the 90s. And we know that doesn't work. Like the idea that we'd have like vans that deliver your groceries, that was such an obviously stupid idea. I can't believe people invested in that. The idea that there'd be like, bike messengers that deliver snacks, like cosmo.com, these crazy .com access, this will never be repeated. And here we are. But in '06, I just remembered it was like the the people that wrote code were like the just one more kind of weird freak that existed in San Francisco next to all the other weird freaks. It's like, oh, hey, it's so cool that like you like coding, you know, you just don't care what anyone thinks about you. That's so cool. We accept you here in San Francisco. And then, of all the different subcultures in San Francisco and ended up being, you know, the techies that, you know, made billions and billions of dollars and really changed the economic landscape in many ways in San Francisco. And I just think it's easy to lose track of how quickly this whole thing has moved. And I think a lot of the very idealistic ideas that I think people had about, you know, information technology 10 or 15 years ago, hey, we just need to give people this and it will, technology will always act to, you know, enable and support the oppressed and the underdog. Well, actually technology with force multiply for everyone, it's just adopted by the outgroups first, it's definitely going to be it's going to be adopted by everybody eventually. So all which is to say, I think that like, what's happening is, we're getting a lot more sophisticated as a society about technology, we're having the conversations we need to have. And it comes from experience. We're having these conversations about, you know, what our obligations are as tech companies, we're having these conversations about the impact dating apps can have on the world, we're having the conversations about the fact that if we have more people from more backgrounds, able to write the apps, if we can write the apps faster, if we can get more voices to the table, you know, I think that's ultimately what's gonna give us that positive impact. We can make app development radically easier, faster and more accessible. If we can empower more people, my own personal, you know, horse of the races. I don't think I'm smart enough to know how we're going to use technology the right way. But I think if we can get a lot of voices into the dialogue, and we can give everybody good tools. I guess I still haven't totally given up that dream that technologies and empowering forks.
SC Yeah, I chose that as well. I hold on to that, too. But once a year, I have the existential question of is the internet a net positive? And so far, I've always come to Yes, but there's been some heated debates internally, every year.
GS I think of it is how do we make the most of the internet? It's here to stay. [Geoff laughs]
SC We can't cancel it. [Sara laughs]
GS Yeah, what's the team we need to build? What's the team? What's the coalition we need to build? What are the conversations we need to have to make the most of this incredible gift we've been given? And that's, that's where I try to sit. And I see some things that challenge that for me too. But I just come back to we're on a path we're all learning, we're learning a society, and I have some hope and some faith about where this is all gonna go.
BP Yeah, you got to fight for the internet you want to see. That's, that's, you know, you can't give up, I noticed that, you know, some of what you had was a determination to build stuff that made it easy, you know, to bring together the data and make the complexity of modern apps easier for the folks who are building them. And this dates all the way back to 2011. And, you know, creating MeteorJS. So can you tell us a little bit about that? And some of the ideas you pioneered there that then went went on to be part of Apollo?
GS Sure. Yeah. You know, 2011 was a really magical time, because this was sort of when apps were starting to happen. And by apps, I mean, not HTML and CSS that we're pushing down to a web browser, but actually, there's software in your browser, there's software on your device. And we're asking, how do we get the data from the cloud into this into this, essentially, a client server architecture is what we would have said back in the day. And Meteor, I think, was one of the first things that really tied all the pieces together for people about how if I know JavaScript, and only JavaScript, I can build one of these modern apps that has this client server architecture. You know, I think we think it was March of 2012, that we released Meteor 0.3.2, the first demo. And that got popular really fast. I remember that by the time he released Meteor 1.0, I think there were local Meteor meetups in 134 cities around the world on the same day, all user organized to celebrate Meteor 1.0. And the reason for that was there was such a hunger to find a new way to build applications. And I think the thing that Meteor does really well is it integrates all the pieces for you. So you know, it's going to line up, how do we do my view layer? How do we do our state management? How do we do you know, the communication over the network? How do we even you know, connect to a database like MongoDB, and constantly watch the database for changes so that whenever anything changes, it's pushed to live updates on the screen. And I think for a lot of people, Meteor was the first time they'd ever seen a lot of that stuff, or even seen basic stuff like full stack JavaScript package management, or see things like hot code reloads, it was the idea to integrate all the pieces together, we can build a great experience. And the goal was kind of build something like the Ruby on Rails for JavaScript. And the direction JavaScript is gone is, you know, there's a lot of people who use Meteor, and they love it. But there's a lot of other people, probably a lot more people that want to put together things from a couple different libraries that you can modularly combine to build your own stack. And I think partly, that's because technology is changing so quickly, there's new stuff like Apollo all the time, you want to have that flexibility. And what's more, you know, and so the trade off for Meteor is you get this great package integrated experience, but you really have to follow all of Meteors opinions. And we were always under a lot of pressure with Meteor to take the pieces of the Meteor stack and make them useful separately. And Apollo was really our first big push on that we wanted to build the Meteor 2.0 data system, we didn't want it to be tied to MongoDB. We want it to work with any back end data source. And we're seeing how quickly react usage was growing. And we said it's very important to be incrementally adoptable. This has to be something you could bring in to an existing application. So we want to build a new data system works with any back end, should work with any front end, not just JavaScript, because JavaScript didn't go the way some of us were hoping on mobile for building mobile applications and React Native has has like been a big boon to that. But you know, like the Cordova, you know, phone gap approach, you know, didn't go quite as well. And we also wanted something that scaled to the world's largest teams, the world's largest websites, we'd start to see enterprise adoption with Meteor, and we had a better understanding of what the needs of the enterprise were. So we said, What if we took this data layer, which is one of the things that makes Apollo really great, what if we make it work with any front end a back end, scale the massive scale and release it as an independent incrementally adoptable component? And that was Apollo. And, you know, it really took off like a rocket. And it's just been amazing to see how quickly, you know, taking that technology, you know, and all the lessons learned from that and making it something that really follows the needs of what people need for like a much larger audience of people who don't necessarily want a full opinionated stack. It's been really cool to see how that's gone.
SC What are you working on now? What are you excited about for 2021?
GS There's a ton of stuff up and down the stack. I think one of the things that's really exciting is the scale that we're seeing graphQL adopted at. And so one of the big, one of the big questions that comes up is, Okay, so I've used Apollo client and Apollo server or Apollo client graphQL job or whatever I might use, to get kind of a first team up and running on the graph. And you know, that team, maybe that team may be really happy. But then you have this epiphany, which is, ''Hey, what about all the other people in my company, they might want to use this too. I've gotten a lot of benefits from this.'' And people, people see some huge like benefits in terms of how many features you can ship at any given unit time when you don't have to build all that product API code. And so what happens is people start asking the question, ''How do I scale this to multiple teams?'' And a lot of questions come up, because you don't really want if you've got 10 teams, you don't want 10 different graphs, you actually want one graph that spans 10 teams. And so that brings a lot of additional stuff you need, you're gonna need a schema server that you can put all those schemas on. And then you probably need to wire that schema server into your CICD process so that whenever anyone changes some part of the graph, you're validating it that bad against everyone, everybody else who refers to that part of the graph. So we're doing a lot of work to support multi team use cases, we already have a great offering there. But as this just gets rolled out to just ever larger environments, you know, two years ago, we thought a million queries a month was a pretty big user. And then last year, we were starting to talk to people on the billion query a month range. And now we're having folks that are, you know, scaling toward a trillion queries a month. And so just following this, like 1000x scaling of like, you know, sort of highly scaled graph rollouts. And and you know, with that is also a corresponding scale the number of people on the graph, the number of different services, all these technologies like Apollo Federation, which is how you can take multiple services, combine them into one graph and do foreign key references. Apollo studio, which is some of the pieces around what are the workflows and business processes and testing flows and security and so on around this, we're continuing to prove all those things. But at the same time, we're also making big investments in, or putting up a lot of resources to continue to contribute to the open source projects like Apollo client, Apollo server, we can expect to see big improvements in graph router technology that connects multiple teams into one graph, we can expect to see continued progress on Apollo client, Apollo server to just give a great experience. We're especially wrapping up our investment in mobile, in terms of the Apollo client versions for iOS and Android. We're also looking at how do we make a great developer experience really from minute one. So Apollo Explorer, I think I touched on that earlier is a great way to take your graph and browse it visually and build queries, whether you are just getting started, you just want some basic functionality, like browsing your graph, and maybe saving some queries, or whether you're working with a truly huge graph, and you have like many, many, many, many, many pages of schema, and you really need a search way of thinking about your schema, not like scrolling through it. Apollo Explorer is a great tool for that that's live, now we're continuing to improve it, the other thing we're doing is we're continuing to make it very easy to get all of that full suite of Apollo tooling, like Apollo Explorer, very easy to get onto that from your first minutes of your development. So it's a whole mix of stuff, a lot of you know, really, really continuing to track very closely what people want in the open source tools and libraries, but also continuing to track, you know, for some of the management tools and the scaling tools, what people need and continuing to supply that.
SC What do you think is the driving force behind your community? Is it people that are using your tools, passionate about it want to change things? Is that where you're seeing the most of people jumping in and, and helping from outside, you know, your employees?
GS Yeah, I mean, I remember all the way back to 2016 was the first version of Apollo client, our motto was ''By the community, for the community.'' And the fact that we thought about graphQL as a coalition, like how do we do this together with other people? Like that was one of my big learnings from Meteor. Meteor, we sometimes thought that we had all the answers, or we needed to have all the answers and we could solve all the problems, or we needed to solve all the other problems, all the problems. And one of the, I think, big course corrections we made with Apollo, you know, for our culture, and our team is saying, we really want to build a broad based coalition and do this together with everyone. You know, I think of us as being facilitators stewards, like we're trying to help people have great tools. And I think when you think about the business model, I think the reality of, quote unquote, open source business models is that you don't pick your business model, your business model picks you. Like, if you want to start a open source company, you have to pick something that is naturally has a part that's naturally open source, and a part that goes with that is related to it, or adjacent to it, that's naturally a SaaS product or something like that.
BP Hmm, that's interesting.
GS So think about GitHub, you know, it's like Git's open source, Git has to be open source, the reason Gits open source is because Bitkeeper wasn't open source. [Geoff chuckles] Nobody liked that. Yeah. And the community fixed that very quickly. The community is very good at fixing things that aren't right. And the community is going to accept us and support us as the steward of those open source projects for exactly as long as that serves the community's interest. And we understand that which is why we come from a point of view of serving the community, At the same time, GitHub, GitLab, Bitbucket, those are all great businesses. You know, people want those things to be managed services. So they want those things to be, you know, commercial on prem products. That's the place where people actually want it to be that way. So you have to listen to people say, how do you want this? And if there's a commercial piece they want, that might be a business. If there's not a commercial they want, it might be more like my 20s, where, you know, I ate ramen software and did consulting for myself, you know, both of those can be great ways to show up professionally. And, you know, just just know what you and your family want or need at that point in your life.
BP Yeah, and I think what you said about if it can provide, you know, value to the individual, and they feel that they can contribute, that's really powerful and community building. And then if there can be a managed service where you get, you know, involved with a corporation that has, you know, a higher bar for what they require, that's a great place to sort of build the business. So those two things seem to sit well, side by side.
GS Yeah, the reality is that, in many of these cases, you find out that a lot of the economic opportunity is in the enterprise. Because many, many, many developers work in enterprises and enterprises are solving some of the world's largest problems and have, you know, resources to match that. And so, enterprises end up having enterprise needs, it's a different set of needs. And so it can, and they want to pay for software, they want to have a relationship, and they want a business relationship, not just files they found on the internet. And they also just have more things that they want that they wouldn't necessarily expect or desire to be open source. I think it all comes down to empathy, it comes down to listening to people, it comes down to understand what do you want? And if you say, ''Hey, this is the way the technology should be based on my ideology'' and you don't listen to people and understand is it meeting their needs? And what do they really want? You know, you can, you can miss some cues. But if you listen to people, they'll tell you, this is how I would like you to release this stuff. And this is how the relationship I'd like to have with you. And sometimes that means understanding, you know, you may not come from a business background, but that journey of listening and empathy may lead you to discover that many of the people using your software are actually businesses. And you, you may have to step outside of your comfort zone as a developer and understand their world and understand how they want it supported and how they want it scaled, and the kinds of functionality they want, how they want it delivered. But, you know, I think there's, there's a lot of win-win opportunities there. You know, the open source communities, a very innovative community, often looking at what's next often asking, what's technology going to change. And I think some of the ideas that we see will continue to spread more broadly. And I think among that will be the idea that we need to create empowering work environments. And we need to create tools that really empower our users. And there's so much power for everyone if you do that, because people get so excited. They they want to contribute. And I think it has to start with listening apathy.
[MUSIC]
BP Alright, it's that time of the episode. Geoff, I always read out a lifeboat badge. So that's a badge that you can get on Stack Overflow, if you answer a question that had a score of negative three or more, and got it all the way up to 20 or more with a nice accepted answer. So today, there is an error in an XML document, 1 colon 41. And we have an answer and make sure your message class looks like below with a lovely code snippet. So thank you to SLL, you earned yourself a lifeboat bag and help spread some knowledge. Alright. I'm Ben Popper, the Director of Content here at Stack Overflow. You can find me @BenPopper on Twitter, and you can send me email podcast@StackOverflow.com if you want us to talk about something on the show.
SC I'm Sara Chipps, Director of Community here at Stack Overflow. You can find me on GitHub @SaraJo and if you're looking for a Christmas present for the holidays for kids in your life, check out Jewelbots.
GS And I'm Geoff Schmidt, CEO of Apollo. Really great to be on the show and you can check me out on Twitter @GeoffQL. Yeah, I actually went there.
[OUTRO MUSIC]