Scott Ford: [01:15:55.02] And one of the things that we’re trying to do that’s unique with Freshly is not just capture how things are right now, but capture how they used to be, and graphing that over time. So these metrics that we’re collecting and we’re computing, we’re mining information from a source code repository, and computing what these metrics would have been like in the past, and graphing that information. And I think the trend can really paint a really interesting picture for leadership, and hopefully get budget for some of these improvement efforts.

Something I’ve seen on a lot of teams is there’ll be engineers on the teams who are aware this is a problem, they want to fix it, they don’t like that they’re living with this status quo, and they feel like their leadership hasn’t given them enough flexibility to really go in and solve the problem. They feel like they’re told to obsess over features instead, and some of these essential maintenance activities get deprioritized.

Mat Ryer: Yeah, yeah. “Is that a wig?” Why would I choose this? [laughter] You know what I mean? Imagine going – have you gone into a wig shop on a budget?

Filippo Valsorda: Yes. Who, by the way, did a lot of experimentation with making open source sustainable, so that’s part of why he’s top of mind. So I really think different projects are well-positioned with different markets, and different segments, and different companies… Although, before you asked what was the hardest part of selling this, and honestly, it was not selling it to companies; maintainers were such a harder sell about this being doable than companies were. Companies most of the time - even if they were negative, they were like “Oh, I totally see that. Our approval process is a pain right now, and we are on a budget, and totally can’t get approved, but I get it.” Lots of maintainers instead were extremely negative, and I get it. I get that anger, and I know that I’ve angered some people that I care about, that I wish the best to, because they tried and they were burned, and they’re like “Ah, it’s just how it goes. Companies just take your project and build a multimillion-dollar company on top of it, and you never see any money out of it.” And you know, it’s kind of exactly what I’m trying to change.

And part of why I’m doing it myself is that I’ve figured that the only way to disprove the idea that that’s the only way it can go was to show an existing proof of the model. I think that a lot of it rests on how legible - and we keep getting back there, don’t we? …you are. Because if you’re just like “Hey, you should really donate to me, because you’re making a lot of money.” Very hard sell. Not because companies are bad people, but because companies are off doing their business, and they have their own internal mechanisms. And if you’ve ever tried getting a donation approved at a big company, you would - yup, no, that’s gonna go through 15 layers of bureaucracy more than getting a vendor approved.

Lars Wikman: It’s a tricky one. I think I’m still a bit in exploration there… Because what my current day to day production looks like is pretty dominated by what my current client is. So I do consulting, and run a team for a product that’s being developed at one of my clients. And they are we run things on Fly. I picked Fly because we – we were doing an Elixir project, and we want to reduce the amount of ops we have to do, and just focus on mostly development.

[06:19] And I will say, I’ve been pretty happy with Fly. It has been a mixed bag, because this – it’s still an early company, it’s still an early platform. So definitely sort of a mixed experience. But they essentially do what a Kubernetes type solution would do for me. They do platform engineering, so I don’t have to; that’s kind of the idea of platform as a service. But I still have to fiddle around with a bunch of YAML, and CI/CD pipelines, and all of that… And currently, that runs in GitLab, because the client had GitLab when I came there.

So I rolled with whatever was there, and made some choices based off of that, based on what I see… Sort of “Oh, the team’s experience level is about yay-high. Okay, we should not spend a ton of our time on the server. Someone else should deal with most of the ops.”

If I needed to get something off the ground on a budget, or if I built my own SaaS, I think I would probably set up a dedicated server for it, potentially to have the failover. It depends a little bit on the service. Not everything needs to be highly available, really… And in that case – right now I’d probably pick up Debian, or Ubuntu, and I’d be slightly - not thrilled with that choice, because it’s not ideal, but it’s what I know well enough. Nix seems like it would be cooler; I’m not sure how convenient it would, be because I haven’t explored Nix yet. There’s, of course, nice things about immutability. But for me, I like to try to package as much of the deployment aspects of the app into the app itself. I run Elixir applications that can provision their own SSL certificates, for example. And whether I would sort of include NGINX, or a specific load balancer, would depend on sort of “Do I need high availability? And in what way do I think I could conveniently provide that?” Sometimes you can load-balance with DNS, sometimes that’s not really appropriate. Sometimes you need something in front of your application, sometimes you don’t. So there’s always those trade-offs, but I like to boil away as much of the layering as possible, as many of the layers as possible… At least when I don’t feel I need the layers.

And there’s a big difference between doing Elixir and when I was doing Python. Because if you were doing Python, and you set up an app server, you absolutely should put NGINX in front of it, because that app server was never intended to meet the world. But when you’re dealing with the Erlang VM, and well-established servers, it’s “Yeah, no, they’re fine.” I’ve seen a lot of people set up Cowboy, which is the common Erlang and Elixir web server, and be “Oh yeah, we had cowboy, and then we had NGINX… And we had an outage on the first big day, because we had a misconfigured NGINX.” It’s “Okay…” Both NGINX and Cowboy can, of course, handle a ton of load, and the more layers you have, the more you sort of have to make sure that they’re all playing nicely. That’s sort of what I want to avoid.

Pia Mancini: I also wanna say that OpenCollective’s data is open. We regularly post all our data on a Google Drive that is publicly accessible, and if you go to a homepage, there is a link to open data, and everything is there. So anyone who wants to do this and run these numbers, and if there’s like any data scientist there who’s like “I wanna see how they spend the money”, please feel free.

One of the things that we are doing though is we’re building proper metrics tooling for collectives and fiscal hosts. So we will have a much better understanding of, you know, “They’ve been spending money on this”, or “From this budget, open source projects normally spend 90% of their budget on a monthly basis” or “They keep their budget forever.” All of that metrics and readings, with the new metrics dashboard for collectives, are gonna be much easier for us to do and have at a glance.

Suz Hinton: That’s really cool. I think that the kind of era of live-streaming becoming something that everybody is able to do in their home now also offers better software package options for people on a budget as well… Like you said, MonsterCat and all of that just didn’t exist for a while, and so before that, I was trying to go to Bandcamp and looking at every single music artist license to make sure that I could play it in the background, and had to artisanally pick things.

And I’m just so stoked that these kinds of demands have actually paved the way for us to be able to do this now… That is one kind of nice thing that’s happened.

Chris Benson: That sounds like a great one. Likewise, Google has their machine learning crash course that uses TensorFlow APIs, and that is freely available. We can put the link in the show notes… They describe it as a self-study guide for aspiring machine learning practitioners. So that’s also one of the many great, free resources out there, where people can get their hands dirty on these.

[14:37] On a slightly different tangent, I have a lot of conversations with people that are trying to figure out how they’re gonna do the computation side. We use cloud services, obviously, from the major providers, and in some cases maybe we’re lucky and we can afford some pretty good deep learning-oriented hardware with GPUs or TPUs or whatever… But there is a YouTube video by Siraj Raval (if I’m pronouncing his name correctly), who is one of the better-known luminaries in the deep learning space. He does a lot of YouTube videos and courses, and he’s fairly well-known for these. He did a “Best Laptop for Machine Learning” video, and it was a good thing that if you’re on a budget, it was a great way of saying “Okay, how could I get into this? If I’m gonna build a system or if I’m gonna buy one, what are those tradeoffs?” and it was just a good basic thing.

I suspect that on the hardware side we’re gonna see a lot more of those types of recommendations as people get more and more into this, as this space becomes more accessible to people.

Gerhard Lazu: Yeah, exactly. So that will be exactly – so let’s just agree on a new budget. That’s it.

Chris Benson: I have an answer for that, but I think it’s a little bit of a cheat on your question… Because I think the question assumes that you don’t necessarily know all the things. But I’ve had the benefit of a little bit of experience going through this process several times now, in several different organizations… So for me, I would hire in to reflect the entire workflow. So I know what a good data science including deep learning workflow looks like these days, from beginning to end; all of those things that have to happen, from understanding the problem, to identifying what kinds of models need to be there, to how you would implement them, what kind of equipment you need for those models, the software, how you do the DevOps or dev sec ops to get those, all the way out to deployment to production.

So from the early conception, almost at the business level, all the way through those various steps to the end, and you have something out there, it’s a model that’s wrapped in software that’s doing something productive in the world. At this point I would catalog those – I know how much effort roughly would go into each of those areas, a ballpark, and I hire against those levels of effort in those different stages to try to get the complete team. And depending on what the budget is and how many people, I will group some of those tasks together, and figure out what that is. It also depends on the candidates I talk to. I may make a change; if I get a particularly capable candidate, then that can change how I’m thinking about things on a tight budget.

Mikeal Rogers: I run incredibly small budget conferences, and still paid for a fair number of the speakers’ travel, and then just a lot of other local speakers filled in the rest. The trick from an organizer’s perspective to do this on a low budget is to set stipends, so you know what the budgeting is ahead of time, and just base ticket sales on the things that you know are going to bring in money, and you can bet on it actually covering this.

So put it next to your venue in terms of what you know that you’re gonna have to pay out, and then rather than doing reimbursements, set stipends so that you know that you can cost-control a bit. And that’s actually nicer sometimes for the speakers as well, because when they’re submitting a talk and deciding if they wanna go to this place, they know exactly how much money they will get in order to travel, and that they won’t have to do this annoying expense reimbursement thing, or convince you to sync up with them to buy their flight, or whatever. It’s actually somewhat preferable to a lot of speakers.

Johannes Schickling: So I would say that right now if you’re on a strict time budget, then local-first is probably not yet for you. I will probably give a different answer – I would have most certainly given a much more stricter answer along those lines two years ago. So I think right now it’s already less irrational to go this path… But given that there is still a lot of infrastructure missing, or it’s not quite as mature yet, I would say maybe in two years from now I would confidently say “Okay the water is pretty warm for those specific use cases.”

I would say the more of a specific use case you have, where you feel like “No, local-first is so perfect for this, and this will give me a strategic benefit further down the road”, for example that you build something where user privacy really matters, or for other reasons… If you have a very specific reason, then I would say actually the water is warm enough that you can swim, or do whatever activity in there. But it’s not a silver bullet yet. It’s not like the catch-all scenario yet. So I think for that you’re probably still better off with your typical three-tier web app. But it is trending in the right direction. We have so many more off the shelf technologies already there, that people can try out. There’s actually quite a couple that are just about to launch in the coming months… So the space is really getting there, and I’m very confident that for this mentioned set of use cases, I think within the coming years we’ll see it flip, that it gets easier and simpler to build apps in this way, in the medium to long term… Since at the end of the day if you build apps that have a rich client-side experience, it’s just by definition there’s a distributed system to be solved. And this is what Notion is struggling with right now, this is where many apps are actually getting worse over time. My Notion calendar doesn’t work offline etc. Those are things that it’s just almost impossible to retroactively address, where you need to choose the right architecture from the get-go. And I think this will be a better starting point in the not so distant future.

Jerod Santo: How much can you really get out of a 4$ VPS? That is what Alice GG was wondering when she decided to perform her own load test to figure out if the promise of running your production app on such a low budget is realistic.

So, she coded up a simple CRUD app in Go, hooked it up to MongoDB because…

Shawn Wang: Yeah. There’s an infinite game mentality to this. But I don’t want to diminish the concept of free, so… It bothers me a little, because Quincy actually struggles a lot with the financial side of things. He supports millions of people on like a 300k budget. 300k. If every single one of us who graduated at FreeCodeCamp and went on to a successful tech career actually paid for our FreeCodeCamp education - which is what I did; we started the hashtag. It hasn’t really taken off, but I started a hashtag called #payitbackwards. Like, just go back, once you’re done – once you can afford it, just go back and pay what you thought it was worth. For me, I’ve paid 20k, and I hope that everyone who graduates FreeCodeCamp does that, to keep it going.

David Kanter: Yeah, so I think that kind of dives into some of what our organization provides, which is – so we do have a budget, and we do use some of that for staff; we hire consultants and folks to help us out. We have a core of very dedicated folks, who are incredibly interested and focused on speech… And a lot of those folks have gravitated towards us, and collaborating with others is absolutely part of this. But I do see some of the benefits that we have is that through the community that is MLCommons we have access to tremendous compute resources. So if we want to start training a model on this 87,000 of speech, which we do, we can go to some of the world’s top cloud providers and work with them to take advantage of the resources that they have, and collaborate together.

But it is true that as a volunteer project one of the biggest challenges is turnover. And this is true in graduate schools as well, and actually this is one of the things that I think is sort of a lesson from ImageNet that we’re trying to build on and improve, which is the ImageNet folks did something amazing on a very tight budget. We wanna reproduce that. But we also think that the techniques that go building these datasets are durable, and by putting a lot of this expertise within an organization, we can drive down the cost over time… Because there’s all sorts of tricks of the trade that are very much embodied in people, and may not get written down. So when you have people rotating in and out, you kind of lose that. But by having an organization behind that, where it’s all written down, and we have some continuity - folks like myself and other leads - I think there is a great opportunity to really build up momentum that is beyond a single project.

Adam Stacoviak: That’s a lot of money. I’m just doing the back of the napkin here… The average shirt costs - if you’re getting them in that kind of quantity, it’s probably pretty low, plus you probably have relationships with a printer, so maybe $8-$10 plus shipping worldwide… That’s still a decent budget, just on T-shirts.

Feross Aboukhadijeh: Nice. Well, I think this is probably a good time to start to wrap it up; we’re approaching an hour… So I just wanna say I think this has been really fun, and it’s just really impressive what a small team of – you guys are just three people… What you’ve been able to accomplish with Beaker browser, and what you’ve been able to ship on such a shoestring budget, and just how useful it is and how promising it seems.

Thanks for taking the time to talk with me today, and for sharing all of your knowledge with the JS Party crew.

Luis Ceze: Good question. And again, this is all happening and maturing fast, right? So our current view is that with the right automation, again, you could have the folks creating models do the best job they possibly can in creating the models that have the right properties, right? And then on the DevOps side, they can focus and continue deploying software the way they do. And I think that the dynamic is going to change that organizations wouldn’t have to go and look for people that are actually specialists in both… Because that’s the reality today. So this team in between folks that create models and folks that run the regular DevOps - these are people that, again, as I said before, understand machine learning, they understand the tooling around all the guts of, say, TensorFlow and PyTorch, and what are the right libraries to use depending on the hardware target, what are the right compilers to use… For example, should you use Tensor IT for NVIDIA, should you use TVM in case you’re going to have broader options of hardware? And then you have to do performance evaluation to make sure that you’re getting the right performance from your model running on the chosen hardware. Often they have to make decisions about the procurement… So if you’re going to deploy it in the cloud at reasonable scale, chances are that your model is going to have a line item on the budget because it’s going to cost a lot of money to run at scale. So you have to go and understand what are the cost implications.

These are the kind of things that none of these teams are used to. It’s not their strength. So DevOps will understand enough machine learning to do that, and then data scientists don’t understand enough of the systems aspects to do that themselves. So I think that the dynamics that’s going to change is if we automate this right, companies wouldn’t have to go and look for this kind of people that understand this intersection, right? And I hope this is going to make it even more accessible for users to put models into production, because they don’t have to go look for people like that. They don’t have to have the systems expertise, coupled with machine learning to make use of machine learning.

Jerod Santo: The marriage comes after the wedding, and it’s way harder and way more important, but… Yeah, we tend to focus on beginnings, that’s for sure.

Okay, so let’s loop back in, somehow… There’s no good segue back to where we were, but we were talking about Ballerina, and we talked about its influences a little bit, we talked about its genesis… You had R&D budget, you had even this skunkworks budget, a couple people working on it to figure out things, like “What’s it gonna look like?” Of course, we have this great idea of the graphical diagram-based underpinnings, but what are the language influences? What does it look like? What came out of it? Let’s talk about the language, its features, and give me the nitty-gritty of what Ballerina is all about.

Daniel Bachhuber: Well, I’m not sharing any of the numbers publicly, because there’s a bunch of downsides to that and not very many upsides. From a perspective of other open source projects that have funding for maintainers to get paid to work on a project, it is a healthier number than that. And I have budget approximately to pay three people part-time to work on a project… And some budget for travel and other miscellaneous expenses.

Mark Christensen: Yeah. Workflow platforms are all about moving off of spreadsheets and manual processes into processes that scale better. That’s what we do. We’re focused on the production process. So everything from training and managing the skilled labor, to meeting deliverables on time, and at quality levels that clients expect… I mean, keeping projects on budget - those are all things that training data services companies like we do, and that we bring to the table. Our focus is on making complex workflows easier.

[00:20:03.28] And another part - this was interesting, that one of our clients said to us one time, is that they needed all of the stakeholders at the company to be able to see what was going on with the project. And the platform, our platform enabled them - and other platforms, too - it enabled stakeholders to do that. And there’s all kinds of stakeholders at the production level and the commercial level for projects. Because projects, on the commercial side - they’re typically done on the request of a client, and in service to a client. And so all kinds of different people outside of the data science team are involved: the sales team, the ops team, the procurement team, the quality assurance team. And everybody needs to know what’s going on. They want to see if the project is on budget, they want to see if the project’s on time, they want to see if the quality thresholds that the client has set are being met… And so a platform gives everybody that visibility, and I really enjoy and appreciate being able to do that for a company, because it does then keep all the stakeholders in the loop. At the same time, it allows the data science team to not get bogged down managing minutia manually. So that’s one of the neat things that we like to deliver.

And then on the services side, the approach is always about managing the workforce successfully. And success in data science and in projects like this is measured in being able to deliver a project on time and on budget, and at the accuracy levels that have been determined or set by the client and by the service provider as being the goals or the project’s objectives.

An example of how this can backfire is when service providers like us enter let’s say a new language, or a new project area, and maybe their client has come to them and said, “Can you do this? Or can you do a project and data labeling in this language?” And, of course, the knee-jerk reaction is always “Sure, we can do that”, but if saying “We can do that” involves hiring a third-party vendor in that target country or target language to do the project, and it’s done in a scramble, it can really backfire. And so hiring a third-party vendor in cases like that can result in a black box approach where you’re unable to adequately measure quality, and where you’re unable to adequately manage deliverables, so that projects wind up running late, or projects are delivered with poor quality data. And then you’re left scrambling to do those corrections on the data internally, or finding another source to do those corrections for you, and it’s a recipe for disaster.

So for us, the way we mitigate that is when we move into a new language, for example, the initial step is to do the hires and do the training ourselves, so that we have our own team and we’re not dependent on a third-party vendor source for that labeling effort. And that way, even though it’s going to take us longer, and the cost might be higher - and there are cost sensitivities that are realities, but the truth is, if you’re using a third-party vendor and working out of a black box, chances are you’re not going to be able to deliver the project on time and at cost. And so your cost and timeline are going to be affected anyway. So we’ve opted for taking an approach that’s more expensive to our clients, but that ultimately delivers projects with a higher quality, and consistently higher quality data, that are on time, that meet the turnaround deliverables, even though the price might be a little higher.

Shawn Wang: [laughs] Facebook also has one… People really care about time to spinning up their environment. But then there’s the whole continuous integration, continuous deployment model, and a lot of big tech companies have their own platforms for that. And then finally, there’s the feedback from production back into development, so the observability platform that they have. So those are the three big buckets, which kind of cover, if you look at it in the abstract, the entire lifecycle of software development.

So for me, I like this as a model, because you can justify it based on numbers. If you can improve the productivity of the rest of your developers by 1% a quarter, then you should have, for every 50 engineers, one internal developer experience person just focus on that. And you have a budget for two of them a year, something like that. That’s kind of like the math that I did. And yeah, there’s a lot of improvement. There’s a lot of room for improvement for building internal infrastructure.

So I don’t necessarily get involved there. I get involved to the extent that I work on developer tools, which are external things that you can buy off the shelf; you can choose to buy off the shelf, or you can build in-house. And so we are one of those developer tools that you can buy off the shelf, that helps you provide a platform for building reliable microservices systems. That’s a really interesting way to think about the blending of internal and external developer experience teams.

Marcin Jakubowski: Yeah, there’s like six that are productizable right now; there’s 22 altogether… Actually, it’s more like 27 the last time I checked. But you have to consider that each one of these items is at least a million-dollar budget. So we did just about right… Two million bucks, we got one or two things out the door.

At the end of the day you have to take the due diligence to make it all happen. Corporate budgets are – you plop down a couple of million on a project, or a startup budget; you plop down a couple of million, you develop a first prototype, and you go to market. Things like that. That’s what it takes.

But in open source, of course, the idea is that “Oh, so many people contribute that we actually share the burden and people pay with their sweat equity and time, just like Linux, and we get it all done, to great benefit to everybody.” Well, it just hasn’t happened for hardware. It’s a mental block. Collaborative literacy.

Salma Alam-Naylor: So the quick ones to fix and to always bear in mind - and I guess, this is where the frameworks have to help us - is alternative texts on images, right? The amount of times you see blank alternative text or no alt attribute… This is the attribute that reads out the description of the image for people who use screen readers. And also, sometimes it’s absolutely bobbins alternative text. Picture of a chair, “Describe that chair to me, please.” I love writing a really colorful alternative text for people… Especially on Twitter when I’m adding pictures, I write sentences and sentences to describe every single part of the image. It’s like little Easter eggs for people who are using screen readers. I think it’s a really fun thing to do.

Missing form input labels. This one, missing form input labels, plus low contrast text, I think is a symptom of the web is designed by designers today. And designers also don’t necessarily have the time-space/budget to educate themselves on actually how a webpage should be made up. And then couple that with a fresh developer who’s working with a new JavaScript framework, who doesn’t have time to be mentored; they’ve just got to get these features out. These designers and developers need to work together to create beautiful functional– it should be function over form.

Jérôme Petazzoni: [55:32] Well, mine would be that we have to stop insisting that updates, etc. need to be distributed over HTTPS; very often when I say that all my security friends and even non-friends are like “No, you don’t know what you’re talking about. It’s very important, because we have this, and this, and this attacks.” And then when I explain, I’m like “No, no, no… Sure, distribute the metadata - list of packages, versions, checksums over HTTPS all you want. But the big bits - you can serve that over HTTP, FTP, etc.” And the reason being that serving over HTTPS costs a lot of money, not because TLS is complicated, and whatever, but because if you’re using HTTP or FTP, you can just let the world mirror your stuff. That’s the way that Debian and Slackware and all these distros have operated for decades, on a shoestring as far as the budget.

If you take the Docker Hub - and I’m not going to give you numbers from when I was at Docker, because I don’t even know if I knew these numbers, and I wouldn’t remember… But just taking the public numbers from the beginning of this year, Docker said in some PR stuff that they had like 15 petabytes of images on the Docker Hub… So storing that on S3 would be at least $300,000/month, not counting transfer. Transfer - again, I took some numbers that Docker published in the beginning of this year, like 8 billion pulls per month. And I went with an average 10 megs per pull, which is really low… That would give you a bill of four million dollars per month, just to operate the Docker Hub, and these are pretty optimistic estimations.

So if only that was mirrorable easily over plain HTTP, FTP etc. and you just served the metadata over TLS, and perhaps have an origin copy over TLS for the one odd scenario where somebody is running this attack against you, or they prevent you from updating etc. I’m not saying that this would have changed the fate of Docker, but I’m curious to see what the parallel universe where things have been made differently in that regard looks like. A world where you can have something like Docker Hub that doesn’t end up costing in the six, seven, eight digits range per month to some company somewhere.

Yann Lechelle: Well, very glad to be on the show with you today. :probabl is a company that is typically known as a spinoff from a research center in France called Inria. And Inria is the place where this technology, Scikit-learn, has been developed over the past 10, 15 years. Not many people know that, and the project has been somewhat protected and sort of incubated within that research center. And after all that time, as you know, Scikit-learn has been adopted, or even probably participated in creating the field of data science, because it is applied math, and essentially has created a sort of paradigm for how data scientists approach data science, typically through two functions: fit and predict. And the French government has a national strategy for AI many, like many, many countries. And the government decided to double down on Scikit-learn. And they came up with a budget, they entrusted the research center with that budget, but then they also asked for the project to be breakeven at some point. And the team said “Okay, break-even is fine, but we don’t do that in the research center. We don’t breakeven. So why don’t we call an entrepreneur to try and help us figure it out?” And they called me.

I have a track record as a software engineer and an entrepreneur in tech for the past 25 plus years, but I’m not a data scientist. So I did my due diligence and I sort of dug deep to find out what this project was all about under the hood. Is it any good? Is the community any good? And of course, Scikit-learn is this quite amazing jewel of a technology, that every data scientist on the planet uses. I discovered that it was downloaded 1.5 billion times cumulatively, 80 million times a month, 22% in the US, only 3% in France… So this is a project that is used all over the world, and :probabl is essentially the spinoff that takes all of the team, including Guillaume here, from the research center, and turns it into an open source company that inherited the mission that was initially given to the research center. And the mission is to build a suite of open source technologies, including Scikit-learn, but above and beyond Scikit-learn as well, for data science. So the scope is large, the mission is noble, and this is what we’re building, essentially.

So :probabl is a one-year-old company, that has already started doing many, many things, and Guillaume is the representative here for Scikit-learn, this technology that is used, again, by every data scientist on the planet.

Quinn Slack: Yeah. Two years ago would have been 2021, the end of 2021, which was the peak of the market; the peak of kind of everything. And I think there’s been a lot of big changes in how companies are hiring software engineers, and budget cuts, and so on. So we’ve seen a big change over the last two years. Code search has grown by many, many times since then…

[00:34:01.11] But what we saw is with companies realizing “Hey, maybe we’re not going to be growing our engineering team at 50% each year.” We saw a lot of kind of developer platform, developer happiness, developer experience initiatives get paused in favor of cost cutting. “How can we figure out what are the five dev tools that we truly need, instead of the 25? Where in the past, if a dev loved something, then yeah, we’d go in and plop down a bunch of money.”

And so we were well positioned because we had such broad usage… And because a lot of companies looked at us as a platform, they built stuff against our API, and every team used it, we were in a good position there. I think though, if AI had not come out about a year ago, then I don’t know what the DevStack would look like. I think you’d have a lot of companies that realized “Hey, we’ve been keeping our eng hiring really low for the last two years…” I’m not sure now – companies see AI As a way to get as much as they were getting in the past, but with less developers. And developers see it as a way to improve their productivity. And I think the missing piece that we’re not fully seeing yet is there’s a lot of companies out there that would love to build more software, but were just unable to, because they didn’t know how to, they were not able to hire a critical mass of software engineers, they were not in some of the key engineering hiring markets, developers were too expensive for them to hire… But all these other companies that would have loved to build software, they were just bottlenecked on not being able to find the right engineers. I think that AI is going to help them overcome that, and you’re gonna see software development be much more broadly distributed around a lot of companies. And that is what’s exciting.

So looking at the overall software developer market, around 50 million professional developers, around 100 million people, they write code in some way in their job, including like data analysts. I fully expect that number to go up, and I fully expect that pretty much every knowledge worker in the future is gonna be writing some code in some way. So I’m not pessimistic on the value of learning how to code at all… But there’s just been massive change in how companies are seeing software development and the structure of teams over the last couple of years.

On Freund: So you said making a dent, which to us is more important than the business model. Eventually – it’s very cliché, especially coming in from WeWork, but we are a mission-driven company, and our mission is to empower every developer, regardless of their background or skill level, to unlock their full potential. And if we do that, I think we’re also going to do really well from a business perspective. Because if you provide real value, people are going to want to pay for it, right?

But teams do have learning and development budgets already, and they, in many cases, don’t know how to use them. So you could be sending developers to conferences, you could be buying online courses for them… But everything is very ad-hoc, everything is dependent on someone finding a good use of that budget. Whereas what we’re saying is, “Hey, just get a Wilco subscription for your team members, and they’ll be able to practice all the time, whenever they want, at their own pace.” And the platform is going to have enough content that they can choose what they want to become better at. And you’ll actually know what they become better at as well.