Simba Khadder:
If you're a data scientist and you're listening to this, you'll understand this very clearly. I'm trying to make it so data scientists don't have to copy and paste transformation code between their untitled notebooks. Because that's what they do, because that's what I did.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today, we have Simba Khadder here to talk to us about Featureform. Featureform is a virtual feature store, and Simba's going to explain what that is in just a moment. Simba, thanks for coming on the show.

Simba Khadder:
Yeah. Thanks so much for having me.

Eric Anderson:
Let's ground everyone in what Featureform is. And maybe it helps actually, at one point you mentioned the inspiration for the name to me, Terraform but for features. I don't know if that helps people understand what Featureform is, but what is Featureform?

Simba Khadder:
Yeah. It's a platform to allow you to define, manage, and serve features. And for people who are listening who aren't machine learning people, a feature is not a product feature. In this case, a feature is just a model input. So models take inputs, which we call features, and it generates an output, a prediction, an inference. So yeah, the problem that we solve is for data scientists, they are constantly iterating on the features. They're constantly taking raw data. If you're Spotify, you have all these listens for example. You might want to generate the top genre that a user likes. You might want to know, "Hey, what's the user's top artist this week?" Consideration on features. You have all of these ways to kind of take raw data, generate features out of them.
A feature store is a way to standardize that. So going to, you mentioned already that Terraform analogy. Before Terraform, I remember having a lot of scripts, and I remember looking at my AWS console and seeing many, many instances, that sometimes I would be good enough to name, or someone on my team would be good enough to name, but otherwise, it was just a mess. There was no way to organize anything. There was no versioning. It was just kind of just a Wild West of infrastructure. And that's kind of where we are today with data pipelines for machine learning. People write their own data pipelines. They push them on Spark, or they have some crazy like hacked together pod on Kubernetes that they use to generate the features.
Featureform tries to standardize that. We give a framework to define these things and then a framework to do versioning, governance, access control. And finally, features aren't useful if you can't serve them for training and for inference, so we do that as well.

Eric Anderson:
So features are, as you mentioned, the inputs to a model, so these are... Maybe if I break down the creative model, you have algorithms, and those, I am not going to say are commoditized, but they're often in open source. Everyone kind of has access to the latest models, and they're often just one command away. And then the other inputs you control are maybe some parameters to tune, how you apply those algorithms, and the features. So largely, the features kind of maybe make the bulk of the inputs to your machine learning work?

Simba Khadder:
I would go as far as to say as a feature is usually the only place you can actually inject domain knowledge as the data scientist. Like, you can kind of get there with the architecture. I don't want to say it's 100%, but on average, that's where you input your domain knowledge.

Eric Anderson:
Got it. And these features are columns in a database, maybe.

Simba Khadder:
Yeah. It could be just a column in a database. A feature could be an embedding, like a vector. It could be a whole image, could be a feature. It's just anything that goes into a model. Typically, a feature store is its NLP or tabular data, so a lot of text, vectors, just floats, you know? Strings, et cetera.

Eric Anderson:
And there's a whole kind of data pipeline that goes into creating these features for end consumption, one to like even prepare them from their raw, terrible state to something usable, and then two, there might be further optimizations specific to machine learning, normalizing them to a certain numerical value or something. And all of that is encompassed in these feature pipelines. Is that right?

Simba Khadder:
Yes.

Eric Anderson:
And what we've called feature stores, I think a lot of us historically, is the place where that end, prepared, and normalized feature gets stored for serving, but you have kind of a broader definition of feature store. Is that right?

Simba Khadder:
Yes. So let me give some context first. I used to go into sales calls, and I would always start, if they've heard of a feature store, I would have to immediately be like, "Cool, I have to unteach some things and reteach some things, because everyone has a different definition for a feature store." And for our products that I would argue are, in any other space, would be completely different categories, but they both call themselves feature stores, so that creates more confusion in the space.
So after having a lot of these conversations, talking to a lot of the other creators of lots of the other feature stores, both internal to platform teams and other vendors, I kind of realized there was three categories that captures them all. The one that we call a literal feature store, which it literally stores features. It's like a cache or database for storing features, and I've found it to be usually not solving the problem at hand for the majority of organizations, the reason being that a feature store provides abstractions, a higher level of abstraction what a feature is, a training set is, a label is, all of these concepts, transformations. But a feature in particular, like when I talked about the Spotify example, the feature was the top genre in the last month. Like, that's a feature. That's closer to the transformation, so if you don't own the transformation piece, it's almost like the wrong level of abstraction, because if I want to iterate on the feature, then I have to iterate outside the feature store, and the feature store is just literally like bits that happen to be the final representation.
So we've kind of kept the feature store name, just because it is how we describe ourselves, but we invented the idea of a virtual feature store, which looks more like an orchestrator plus metadata. It's kind of an application layer on top of your infrastructure, that is aware of what you do as a data scientist, as a machine learning practitioner.

Eric Anderson:
Got it. So in Featureform, I might describe tasks that need to get done, and those get farmed out to other pieces of infrastructure, some of which we're familiar with, right? Task queues or orchestration frameworks, and mix and match those, if I understand correctly.

Simba Khadder:
So, let me maybe explain, in the very emotional way, the problem at hand. If you're a data scientist and you're listening to this, you'll understand this very clearly. I'm trying to make it so data scientists don't have to copy and paste transformation code between their untitled notebooks. Because that's what they do, because that's what I did. I used to have a ton of untitled notebooks. I used to have a Google Doc of SQL queries and SQL query snippets, that were just useful to use, and I am not alone in that. I know that, having talked to a lot of different orgs. I just said this to someone over the weekend, said the same analogy, the untitled notebook, and she's a data scientist at Google, and she was like, "I feel personally attacked by that, by comments," because it was so clear to her, that yeah, that's what people do. So the problem to be solved is an organizational problem.
Now, there's another problem, which is handling low latency serving, handling N terabytes of data. We would call that the processing problem. We actually to try to solve as little of that as possible. We push that off to our partners, like Databricks, Confluent, like Redis, like DataStax. You name it, we work with them, and we just solve the application layer, which is giving those abstractions so that data scientists can not just write code in notebooks, but actually define transformations, features, labels, training sets.

Eric Anderson:
Makes total sense. We want to go into the kind of origin story for Featureform, which I assume is largely your story, and maybe some of these pain points. So let's get into that sooner than later. What caused you to want to work on this?

Simba Khadder:
I was at Google for a bit, left Google, and started my first company. I didn't start my first company because I had this amazing idea. Well, I had no idea, actually. I had a name and a logo. I didn't have this illusions of grandeur. I just was kind of really young, and just the idea of working at a big tech company for 40 years and retiring was so like not what I wanted to do with my life that I just was like, "I'm going to start a company, just to jump in the deep end and see where life will take me." And it took a while, but eventually, it started to really work out, profitable. We were doing well.
And the part that's relevant here is that we were handling over 100 million monthly active users' data, and we were doing recommendations. We were doing big recommender system models, which create user embeddings, create item embeddings. We did a lot of very cutting edge stuff, that even we were doing it five, six years ago, and now it's starting to become kind of mainstream, some of the methodologies that we were using. I mean, we didn't make them up. Google, at YouTube, released a paper that we based it off of many years ago now.
But yeah, there, I found that most of our value, like driving... At that point, we weren't trying to make our models better to get a new paper in. We were trying to get our models better because it actually equaled user value, which in the end equaled revenue for us. And we realized that iterating on the model, very scary, very painful. It's like a black box. It might work, but if it works in training, it might not work in production, because we're doing recommender systems. We were working with humans. Humans don't work like raw data, or they're really, really hard to do machine learning when it comes to people. So we really didn't like iterating on the model. We liked kind of using generic models, like you said, off-the-shelf-ish models, and focusing more on the features. Because the features, we could control.
I'll give a very specific example. One of the biggest like point increases in one of our models is performance. This model in particular was able to predict if a user would subscribe. Biggest point of value we did is we added the user agent kind of parsed out well, which essentially was what kind of devices is this user on? Turns out, if someone's on an iPhone X, that was brand new, an iPhone X, and you cross that with location, like they're in San Diego, they're on iPhone X, and all these other details, that actually tells you a lot about the user, and it would make them all predict way better, and the best part is we understood why. It wasn't like, "Huh, we added this extra layer. We did this crazy thing we read in a paper, and it works better. We don't know why, but let's just put it in production." It was, "Hey, this works better, and it makes sense that it would work better. It is signal."
So we were spending a ton of our time feature engineering, and then we got into the problem I kind of was talking about, the organizational problem. Like, so much crazy stuff we did. I mean, if you make a lot of slide decks, if you were to open Google Slides right now, I'm sure you have the same presentation of like "_v4_final_donttouch." We had the same things. It just was in our notebooks. And so, Featureform, or at the time, just our data platform, was a way to mostly solve that. And we realized it was really valuable. I realized that this was a much bigger opportunity.

Eric Anderson:
I actually wanted to ask you about the old companies. Is that still in existence, but you've kind of gone 100% on Featureform?

Simba Khadder:
No. We were using the revenue to kind of start what was... Featureform was originally called StreamSQL, and we told all of our customers that it was kind of a one-year like, if you're on a contract, we'll honor the contract, but we're not doing any new feature requests, and if you want to get off or stop paying, we let people exit a contract early. It was not easy to do, but it was the right move, and there's a whole long story of how [inaudible 00:12:22] co-founders, and it was an interesting time of my life to say the least.

Eric Anderson:
I can't imagine. But regardless, you made the tough decisions as a group, and now here you are on Featureform. And then the decision, open source or not. How did that play out?

Simba Khadder:
It was actually very easy. I decided to open source because I just can't imagine a winner in this space not being open source. Even though I love open source, I think open source is great, I'm not going to say it was like totally from a ethical reason or anything. It was entirely just like a business case, like companies that win in the data space and the ops space, they're open source. There are exceptions, like Snowflake is an exception, but you're kind of fighting upstream, I think, if you try to go proprietary. I mean, the point is, if you look at any big data company, even Snowflake, Snowflake makes like 40 million a year off of just Capital One. If you look at most of these companies, they make all of their money off of a handful of Fortune 500s. Whether you cut off the long tail of revenue or not, you're probably still fine, you know?

Eric Anderson:
That's a good point. The bulk of the revenue is going to come from enterprise contracts, and they're going to pay for those whether you're open source or not. Good. And you had a good run in open source, it looks like. I was looking at this launch, was maybe a little over a year ago, a big bump of interest about a year ago. What was that?

Simba Khadder:
Yeah. When we first released it, I think what it was was there was a new player in the space. Like, it was a space where I think feature stores in general, I think a lot of people were, and maybe still are, kind of disillusioned by this space. There was a lot of hype around it, and they looked, and they were confused. Again, partly because of the thing I mentioned earlier, of there's a lot of people calling themselves feature stores, that maybe cause more confusion. "Is this a feature store? Is this a feature store?" An example was a lot of feature stores, like literal feature stores, didn't support transformations, and people were confused. They were like, "Well, isn't that the whole point? So why would I use this thing?"
So I think firstly, there was kind of a new player in the space. We had this new take, this virtual feature store idea, and that drove a ton of interest. We launched on Hacker News and on Reddit, and that just drove a lot of hype and inbound interest, and it worked for us, because it kind of... It was actually kind of a little overwhelming, because it was a little more than we were prepped for. A lot of people started using it. A lot of people found bugs. A lot of things were broken. But it was great. It allowed us to focus in, essentially stop marketing for a bit and focus on product. "Now that we have kind of an influx of users, let's make this thing better around them." And that's kind of what we did for a while.
It wasn't until not that long ago that we really kind of started feeling like, "Hey, I think we've got something. Like, I think it's clicking. People are using it, and they love it. Let's really start putting more gas down."

Eric Anderson:
So maybe let's transition to going back into kind of what the ML ops landscape looks like. I worked in data processing before coming to Scale. I was at Google Cloud working on this thing called Dataflow, and we worked with the Tensorflow team to help people with their feature pipelines, and one of the things we took as a rule was that you should capture the full transformation pipeline in training, so that that could be reused when it came time for serving. We kind of wanted to make sure you manipulate every bit the same, so that the model sees them all the same way. And this idea of capturing the whole feature pipeline, I think's not new, but we haven't really figured out a standard way of doing it. And that's part of what Featureform gets at, if I understand correctly.

Simba Khadder:
I had a good talk with another feature store creator, which is they built Feathr at LinkedIn. And the thing that we really agreed on was the problem to be solved for most of ML ops is abstractions. It's providing the right abstractions and then implying workflow based on it. Like, the thing you're talking about, which is having all the feature transformation pipeline exist so that you can have training and inference be synchronized, essentially, like make sure it's the same data going both ways. That's very true. I think it's just almost too low level. As a data scientist, I don't really want to think about that. All I want to think about is, "This is what my transformation is. It is like an aggregate of user listens in the last month." And then yeah, just like make it so. You don't have to think about it.
This is maybe my take on ML ops as a whole. I think ML ops, a lot of people, we create a separation in our head between the ML platform problem and the ML ops problem. The ML platform problem is, "I need to handle this much data. I need to be able to serve this type of model with this latency." These are processing-oriented problems, and we call that platform problems, because they're usually pretty binary. Usually, you have some requirements, and then once they're solved, they're solved. You could always make it better, or maybe it's cheaper, maybe there's value in making them faster, but sometimes there isn't. Sometimes you're like, "Hey, this thing, we make a prediction every 24 hours. We don't care if it takes five minutes or an hour, because it doesn't matter." That's the ML platform problem.
I think the problem that we focus on is... So that's like the day one problem. You don't have any ML if you haven't solved the ML platform problem, or you don't have any ML in production if you haven't solved your requirements. Whereas the platform problem is about scaling CPUs, the ops problem is about scaling humans. And it's actually a completely tangential problem in a way, because you can have thousands and thousands of data scientists working on relatively small datasets, which we see sometimes, and they're working in pandas. They're working like, "We don't need a giant Spark cluster," but they have tons and tons of problems, and if I was to go to them and tell them, "Hey, like we handle streaming, and this and that, and this," they don't care.
Their problem is, "Hey, well how do we do versioning? How do we do access control? How do we handle if X person leaves the company? Like we're screwed. This whole model, this whole team is done." Those are the problems that we aim to solve, and I think we do that in providing the right abstractions and definitions, and understanding the workflow that exists in ML, but really focusing on the management piece and the organizational piece, and once we have that data, we can assume that, "Hey, by the way, if you have a transformation, I need it in training mode and I need it in inference mode." So we can kind of orchestrate infrastructure, and we can... We already know what you're going to do, because you do what everyone else is going to do, because everyone who does machine learning does inference and training. So yeah, a little tangent maybe, to what you were asking, so I can give it to you... pull it back a little bit, but that's kind of what I think about the space.

Eric Anderson:
No, it makes total sense, and you're right. Explaining to them as like a coordination between people problem versus a platform, performance, scale problem, helps a lot. And in the world of software, we arrived at kind of version control, and Git, and these workflows that allow people to scale engineering teams, and I assume that... Or it sounds like what you're describing is that Featureform allows people to coordinate their work to scale machine learning teams.

Simba Khadder:
Exactly. And that's a problem to be solved. And unlike DevOps, where in DevOps, even in the early days of DevOps, there were at least some companies you could look at as gold standards. Like, Google had Borg way before Kubernetes existed. There were some gold standards. In machine learning, I used to ask this on my podcast, like, "Which company does it really, really well?" And I never really get an answer. It's hard to think of a company... There are companies that do well. Don't get me wrong, but I don't think anyone would say, "Yeah, this is the gold standard of how ML ops should be done." It's really a confusing, I guess, time in that way, because there is no North Star to aim towards, like, "Oh, let's do it kind of like Google." It's just kind of everyone's just sort of figuring it out at the same time.
And like DevOps, like you mentioned, I think the people who will win are the ones who build point solutions that are focused on the right abstractions and workflows, like HashiCorp with Terraform as an example. Like, the hard part of Terraform was not the technical parts. It's not easy, but it's not something that no one else could have done. But coming up with the right abstraction, API design, that's really hard, and also, it doesn't scale well. You can't get 1,000 people and build a better API than 10 people, which gives startups a really big benefit in this space. Like, if Google wants to build the best feature store API, they're just going to have to find 10 really, really smart people to go after that problem. They're not going to be able to just throw 1,000 people at it and beat us just off of sheer force.

Eric Anderson:
I certainly feel what you described as like a handful of unicorn startups have built machine learning platforms, and then we looked at them and it's like, "Oh, that actually helps in these ways, but I don't need this thing or that thing." In some ways, it felt like they were shipping a lot of their... not their org chart, but just the way they did work internal to the... It was specific to them. There were kind of dependencies that weren't generalizable. So you're right. We haven't had a North Star on how this should work. And then you're also right that the abstraction is kind of an intellectual challenge more than a computing one. How do you get the input? How do you talk to the right machine learning engineers? How do you see the future in what this abstraction should look like, when folks at name your once big tech company struggle to build it? And maybe it's that they weren't trying to build a generalizable one. You know, they were trying to solve Airbnb's problem, or Uber's problem, or Google's problem.

Simba Khadder:
I think it's a really good question, and I still kind of... The short answer is there's kind of small fixes. Like, you talk to someone, you think of something small, you tweak something, but the big things, it's more of an art than a science. Like, it's just these moments where even the virtual feature store idea. It wasn't a obvious thing. In fact, the way I came to it was I was selling what would kind of look more like a traditional feature store. Like, it did all its own compute. It was more heavy. Like sure, we outsourced it to Flink and Pulsar, but it wasn't like something you could just easily deploy. It was a big solution, like how a lot of feature stores look today. And people wouldn't buy it, because they loved the idea, but when they came to like, "Hey, we have to replace this, and rewrite this, and do this, and hey, we're a major bank," wasn't going to happen. There's no way.
And so, it was a little bit of that, and so that was the problem, but the idea was one day, I just kind of... It clicked. I was just like, "Huh. How about if it looked like this?" Actually, someone had said "virtual feature store" in a different context, and I just really started thinking about that term, like "virtual feature store," and I came with a different conclusion of what that should mean, and it's kind of what we have today.
I think the other thing is there's a lot of... If something worked at Airbnb, or Uber, or whatever, it doesn't mean it's going to work for everyone. A common thing here is if you talk to a lot of people who work on feature stores, they actually think that feature stores aren't really that useful if you're not doing streaming data or you don't have realtime use cases. And I don't think that's true at all, because I think the organizational issues are still there. Doesn't matter if you do batch. The problem to be solved is still versioning, managing, scaling out, the lineage. All of the things that you would have to do for feature pipelines still exist if it's batch, if it's done every 24 hours.
But I think everyone's really kind of pigeonholed themselves around the specific problems that Uber and Airbnb had, and those problems, they had the organizational problems, but the problems that they literally couldn't just ignore, or just hack around, was the processing problems. Like, if you can't actually do realtime feature serving or realtime feature engineering, you can't do much. Like, you have to solve that problem. So they put tons of resources into solving that. I mean, I know a lot of these internal platforms that have large teams at well-known companies don't have UIs and don't have feature sharing, which we consider to be a pretty critical part of feature stores.
I asked one person who I won't say the company, I won't say the person, but it was a well-known tech company, internal kind of platform feature store that everyone in the company, not everyone, but a lot of people in the company used. I asked how they do feature sharing. He said, "Oh, we just copy and paste." I was like, "Well, you haven't solved the organizational problem at all. You've just entirely focused on the other problem," and it made sense for them, because that was like the key problem at hand.

Eric Anderson:
Yeah. I'll convey some of my naivety here, but if you're just capturing the transformation steps, you could say, "Well, I could capture that in Git today," but you're not. You're also kind of versioning the data that's produced, and there are folks who've tried to produce like versioned data systems, but I guess in a sense, you're combining both of those in kind of one thing. Is that correct, that you're versioning both the pipeline transformations as well as the data that's produced by those pipeline transformations? Is that what makes the need for a new thing here?

Simba Khadder:
Yeah. I think there's a few parts. One is, I wouldn't necessarily say that we version the data as much as we version the definitions, so we can recreate the dataset via the definitions. So that's one, I think difference, from kind of a traditional dataset versioning. Because if I have a versioned dataset, but I don't remember how it was built, it's a different problem, you know? So that's one thing. The other thing is we actually do feature serving. We do that synchronization across offline and online. We do backfill, point-in-time correctness, which I won't really dive too deep into unless you want to, what all that means, but do just very specific things that exist for features. Like, we understand what the machine learning problem to be solved is, so we're not necessarily like more generic than something like Airflow, which in theory, you could kind of build something like Featureform with Airflow, but you'd just end up writing a lot of custom stuff that we already do, and we're optimized for your use case. So we're more narrow, but we solve the use case better. I think that's kind of a key difference.
The other thing with Git, just to... You didn't quite ask this, but it comes up sometimes, like, "Well, can't I do versioning on my notebooks with Git?" And the problem that we run into there, [inaudible 00:26:15] with features, it's with features unlike metrics, like with MRR for example. If you have a company MRR metric table, like per quarter, there should be one, right? It should be right, you know? You shouldn't have 100 of those. In machine learning, like you said, features can have different scalings at the end. You can have different flavors of features, and they all exist at once. And they're useful for different models for different reasons.
So a feature store, a virtual feature store, is able to keep all those versions in existence. It understands why you'd want that. It understands, like within a notebook, it understands, "Hey, this is a feature. This is a training set. This is a label. This is a transformation." It's a different level. Like, we view keeping track of notebooks and keeping track of the machine learning resources that you happen to define in the notebooks as different problems, so we're almost a repository of these resource definitions as opposed to just straight-up versioning of the files.

Eric Anderson:
No, perfect, and then once you capture that feature definition as you say, you can hang all the feature lifecycle things that everyone's repeating in every organization. You can kind of have a standard way of solving those feature lifecycle problems.

Simba Khadder:
Well, I love that you said that, because that's kind of the magic here, I think, is the next step. We're seeing this already with some of our enterprise users. It's like a CRM. Like, for a single person or a team, it's kind of a glorified spreadsheet. It understands the sales process a bit, so it can kind of help you, and it's more valuable than a spreadsheet, but it's at the enterprise use case that the value becomes extreme, because the value of Salesforce to a large organization is not the basic vanilla deployment. That's not what people use at that level. They almost use abstractions and build on top of them, and they kind of define their own workflow, sales workflow in this case, into the CRM.
And we're seeing that with Featureform. We get requests like, "Hey, we don't want this feature served in production until it's been checked off by these people," or, "Hey, legal has to do this," or, "Hey, like these kinds of features, we want to make sure that they're never used by a model that we tagged with this tag, because we're not allowed to use it in whatever," or, "If the user has this location, don't use this feature." These are all things that we think should be... logic that should be embedded within the feature store itself, because it's feature logic. It's feature workflow and lifecycle logic. So I think that that's the part of ML ops and feature stores that hasn't really been explored too deeply. I know that other people are doing it, I assume, are working with these large organizations as well, but I think that we don't talk about it enough. That's really where feature stores are going. They become this platform that ties together all these cross-functional organizations and provides that lifecycle and abstractions around features.

Eric Anderson:
Simba, I wanted to ask you kind of one off topic question. You mentioned at the beginning that open source or not, the end goal is to attract these enterprise customers. But I imagine some of your early adopters are individual users, maybe hobbyists on occasion. Maybe they like the open source. Tell us about the journey as an open source founder in attracting enterprise attention eventually. I imagine that's part of what you're going through now. What does that look like? How have you found it?

Simba Khadder:
One thing that's different, that I've learned... My last company was very top-down, like you'd cold email a VP, you'd sell it. This is also true of a CRM. It's not ICs buying the CRM and the VP picking it up. With developer tools, even if you go to the VP first, and you talk to them first, they're going to push it down to their end users. Like, the ICs make decisions, and you have to make the ICs happy. You can't just be like, "Oh, who cares what the data scientists think? This is going to make your organization way more organized or whatever," because the ICs will fight against it. And I'm seeing this a lot right now in ML ops, where ML ops teams are deploying solutions that data scientists hate or won't even use, and they're kind of patting themselves on the back like, "Hey, we solved this problem," but to do it well, it has to kind of make everyone happy.
So I think to get to the enterprise level, assuming you're going bottoms-up like we are, those same people... Like, if you work at a large bank and you're doing data science there or ML ops there, you don't think of yourself as necessarily like, "Oh, I'm like an enterprise user. I'm boring. I only look for enterprise..." You need those things checked off, but that's just to make your manager, VP, or director happy. So you look for them, but like, you still view yourself as an engineer like anyone else, whether you're working at a startup or a big company. So you start with those same problems. This is true of like Kafka, right? Like, Kafka obviously has different problems that it solves for an enterprise, but engineers... [inaudible 00:30:45] kind of start at first principles, like the engineering problem, so I think that the core here is just solve your users' problem. Make them happy, and they will find out about you. Like, enterprises are... Their data scientists and engineers are also looking at Reddit and Hacker News. They're not like going to some stodgy enterprise engineering forum.

Eric Anderson:
No, totally. I imagine the best machine learning engineers, you have to win them over, and they're going to be employed at the most exciting machine learning areas, and that's where you want your product to be used. Good. Simba, anything you wanted to add?

Simba Khadder:
Yeah. I mean, Featureform's open source, like you said. Like, we have a repo. You can just Google Featureform and check it out. We've written a lot about this before, and we have a local mode too, which I think is really new and interesting of us. You can literally just start using Featureform after a pip install, don't have to deploy anything. So check it out. We have a Slack community if you find anything and give us some feedback. Please do.

Eric Anderson:
Awesome. Thanks for joining us today, Simba. You've got an amazing story, and we're going to follow it closely. Maybe we'll have you on the show again.

Simba Khadder:
That'd be great. Thanks so much for having me.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson, and this has been Contributor.