Shirshanka Das:
Our goal is really to help people get to where they need to get to and not have to change how they work with data necessarily. It's just about reducing the friction they have in working with data.

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.
I'm excited to have Shirshanka Das of the DataHub project to join us today. Thanks, Shirshanka.

Shirshanka Das:
Thanks Eric. It's fun to be on open source podcasts, so I'm very excited to be here.

Eric Anderson:
So DataHub has quite the history. For the unacquainted, they should go watch the YouTube video on the website, because I just went through and it's great. But I feel like we're coming on 10 years of your journey here.

Shirshanka Das:
Yeah, it's been a decade. It's phenomenal when you think about it, a decade of a lot of work that has gone into the project. It started out very small, small search and discovery tool that I just petitioned that we should build, and here we are, it's a full-sledged big project.

Eric Anderson:
What is DataHub maybe today? And then we'll go back a bit and discover all it used to be, but how do you describe it to people?

Shirshanka Das:
The best way to describe it is as a metadata platform. There's no other better word for it. Some people take a step back when they hear that and they go, "Well, can you explain to me what each of those words means?" I mean platform, most people get it, it's something that probably provides some sort of a service interface. It's probably storing some stuff that's important and retrieving it back. Metadata itself is a tricky word. What is metadata and what's data? That's a very philosophical topic. But for most people, they understand tables, and they understand that tables have names. They also understand that tables have schemas and owners and partitions, and then attached to tables are sometimes views, and then attached to those views sometimes are queries that then produce other tables. Once in a while there's an orchestrator that comes along and reads those tables and writes another table.
And then on the other side of that table, maybe there's a BI tool that's actually taking that table and visualizing it in a chart or a dashboard. So really our goal is to take all of these different data assets and data adjacent concepts and stitch it together in one single graph backed by a platform that can allow you to get all sorts of access on it. You can store it, you can read it back, you can search it, you can query it as a graph, you can query it as an analytics warehouse, and then you can build a bunch of use cases on top that allow you to achieve whatever you want to achieve with all of metadata. Tons of use cases.

Eric Anderson:
We haven't said data catalog yet. Is this a data catalog or is that probably a word we're avoiding because it means something to some people and different things to other people?

Shirshanka Das:
Great question. The data catalog for us is a use case on top. It's an experience that you build, or a set of functionality that you build, on top of a metadata platform. And the definition of a data catalog actually has been intuited over the years by just observing products that have labeled themselves as a data catalog, versus having a pure definition of it that sustains over time. I actually have a lot of problems with the word catalog when used to describe this category because... Pop quiz, Eric, what is the first word that comes to mind as a synonym when I use the word catalog? What do you think of from the physical world?

Eric Anderson:
Oh yeah, I don't know, a menu or a... I don't know.

Shirshanka Das:
Most people say that it reminds them of all the junk mail that shows up at their doorstep and they have all these product catalogs from all these different companies that are sitting there. And in general, a lot of the thinking around this area has been a lot of curation, a lot of effort having been put in to create the perfect catalog for your data assets. And the great fallacy in that thinking is it assumes and presumes that your data is static, there's not much that's changing, and so you can go through the effort of creating a beautiful library like experience when it comes to looking and browsing through your data collection. And there's nothing wrong with that dream, I think in fact it's a great dream to have, but the way in which you go about it really determines whether your strategy will work or not.
And for, I would say, the early part of the last decade, we've spent a lot of time and energy as an industry building products that have focused too much on the consumer and the manual curation of it all, so there's a lot of, I guess, clean room governance efforts that have gone into establishing teams of excellence, whose job it is to catalog the business data that exists in the company, make sure that it is consumable, usable, and by the time they're done, the organization has moved on and a lot more data assets have been created and those are really driving the business. So you're looking at a satellite or a moon from 20 light years ago or whatever and saying, "This is what it looks like." So that has given the whole space a bad rep because, similar to data warehousing, it's actually very interesting, a lot of similarity to the data warehousing journey itself where data warehouse teams, central teams doing warehousing have often run into this problem, that by the time they have managed to harmonize the organization's data model and make it usable, the business has moved on.
And so the same thing repeats itself with metadata if you do it wrong. So that's the reason why I don't try to talk about it as a data catalog, but in terms of functionalities, absolutely, being able to search, find reliable, trustworthy data assets, being able to understand lineage all the way from your operational systems to your analytical systems and then back out to SaaS tools.
And not only that, really being used, not just by humans, but also by systems. I think one of the biggest failings of this category has been it's over designed for humans, but hasn't been designed for systems and machines to talk to each other. And so when an AI model is getting served in production, can I quickly make sure that it is actually certified for use? Can I make sure that it's got the right compliance metadata associated with it? It's got the right retention rules that have already been applied? Those are all things that, if you don't think through them as fundamentally tied at the hip, you end up funding and building it using different solutions, and then those two systems don't agree with each other. And then you've got a different divergence that you're dealing with in what you're stating to the auditors, versus what your users or customers actually see on the product

Eric Anderson:
To your naive description where people imagine they can describe everything in the perfect world, I also find that VCs or others will assume a much simpler data landscape in companies than really exists. They'll be like, "Well, don't they already have a snowflake?" And I was like, "Well, yes, and they have a Teradata, and they have some BigQuery, and they've got all of the things." A big bank is going to have one or two of everything, and I feel like part of the goal maybe isn't to arrive at a perfect world, but it's to arrive at a better world where you've corralled the mess that is modern data systems.

Shirshanka Das:
Absolutely. I think innovation is going to push companies forward. There are always going to be different teams that will want to have autonomy to choose the best in class tool for doing their job. And the organization's job is not to really limit that innovation or the adoption of that innovation, but to try to achieve consistency in spite of it.

Eric Anderson:
So I have a question for you. I wonder how you would think about this question. There's some talk today about how databases are being decomposed. This is mostly on the OLTP side, like Postgres has all these extensions now, but in big data world, Hadoop was a decomposed database by some measure, it was on a file system, and then maybe Snowflake feels like the most fully recomposed database, and now there's talk of data lakes again and we're decomposing. A metadata platform, is it a component in a larger data system that could be a component in a composed database, or is it always something independent that's gathering several different parts?

Shirshanka Das:
Great question. I think there's almost two different valid answers to this question. The first almost speaks to the need for a project like this almost, which is that there will always be fragmentation or multiplicity in the data stack. And I'm not even talking about the fact that there will be more than one relational data warehouse that people might choose, I'm talking about even the journey of data itself involves one or two or three systems because even the act of producing and consuming data involves a bunch of transit points, even you've only chosen one per stack. So that's the simplest reason why you need this thing to live outside, but you add innovation on top of it and you find that pretty much every segment has two or three tools that are doing something, the segments themselves are coalescing and splitting every once in a while. We see this duality of code and data at rest showing up all the time. Are orchestrators producing data or are databases storing stored procedures and materializing on demand? And a lot of this stuff ends up creating ripple effects.
But if you look at it from a data strategist's perspective, and I had that role back at LinkedIn, my job was I was responsible for the entire data platform, and I had to basically make decisions around, how are we going to ingest data? How are we going to manage it? How are we going to surface it? How are our AI and data practitioners going to quickly produce relevant and important insights? And I had to make all of those decisions while all of this innovation was going on. Hadoop was a new thing back then, Spark was a about to be important thing, and then there were so many other systems being built around that time. And so the only way for folks in that position to make good decisions is to, as much as possible, future-proof the APIs and the policies and the way they think about how these things connect to each other and leave it flexible about what exact technology they're using to store their operational data, what exact technology they're using to stream their data or process the streaming data.
And so when you look at it from that perspective, from someone who has to design a system or a data strategy that's going to survive over multiple generations of technologies innovating and evolving, you come to the realization that some things that are company-specific, business-specific and that are logical in nature, need to stay outside, because it's foolish to the fact that the customer object looks like this and it has these PII characteristics and things like that, it's foolish to take all of that and then just hard code implement it against a specific database technology's API, even if it supports that capability.
The ideal way you want to do it, and we'd see this in software design, you build interfaces, and then you have implementations of those interfaces and you try to keep the API and the implementation separate. So you'd have a logical layer where you store all of these logical specifications like, "Here's what customer looks like, and here's how I want to manage it, and here's the fields of customer." And then you want an operator or something like that that basically takes that logical specification and then deploys it into the specific physical asset. And so we think about metadata platform as two sides of the same coin. The first is visibility, actually being able to see everything that's going on across all of your different systems. And then the second, and this leads into a control plane way of thinking about data, is not just visibility, but actually being able to declare what you want to see happen, not just observing what has happened or what is happening.

Eric Anderson:
Let me take you back to the beginning because I think your story is amazing, and I'll throw out a couple elements of it. You already mentioned you came out of LinkedIn and the project was incubated there. The project's grown to incredible levels, 8, 9,000 GitHub stars, and what's maybe even more impressive, you have more members in a community than you do GitHub stars, which I'm not even sure how that happens. And so tell us about how this project's grown, because I feel like it's taken on a life of its own and you've been there the whole time.

Shirshanka Das:
Yeah, so like you said earlier, the project started in 2013, I had just taken over as the architect for the big data team and I was confronted with a lot of mess. Everything was disparate, everything was being done differently. And the first thing I did was try to standardize a few things, like data ingestion, data management, et cetera, et cetera. But even after all of that standardization, I realized that there was still quite a bit of problems that hadn't really been solved. There were people joining LinkedIn at that time and asking questions like, "Where is this data? How do I get it? How did it even get here?" We were at that time moving from a relational data warehouse to a data lake strategy, and people were asking, "What's the official source of truth for this table? Is it in Teradata? Or is it in Hadoop? Or which one do I use?" Just a lot of questions about, where is this data and how did it get here?
So that led to actually creating a quick project called Warehows, the question where, and the question how, merged together as a single project name. And that was really DataHub V1, it was called Warehows, and it was really just a search and discovery portal, and we just crawled a bunch of logs and a bunch of assets and built a quick and dirty search interface to quickly go and query data and find what we were looking for. And that thing lived for a while, three years or four years, it had a few good things going for it. And also we learned a lot of lessons around why even the quality of that metadata being good is important, because people were losing trust in it very quickly because we were scraping it from logs and all of those pipelines would break every once in a while and people were like, "Well, I searched for this, it's not here, so I guess Warehows isn't that good." So that was one of the things we were tracking.
And then in 2016, GDPR came along, as in the regulation started becoming top of mind for LinkedIn's leadership, and I was given an offer I couldn't refuse. You know how you get volunteered in an all hands meeting, and before you've had a chance to actually understand what exactly you got signed up for, you were it. So that's what Igor did to me, he was a head of data and CDO at that time, and said, "Well, Shirshanka, you've seen the whole journey of data, you've been part of the online space, you've worked on streaming, and now you pretty much know everything to know about the offline space, and turns out LinkedIn needs to get GDPR right, and we really care a lot about member privacy, so we are going to do it right, and we are going to do it ahead of time."
So this was 2016, and I was tasked to be GDPR lead. Even the laws hadn't been fully fleshed out really then, the LinkedIn legal team was still working with... And there were a lot of back and forth going on around how many of these laws are even implementable using the technology of the day and things like that. So I got really involved with the legal team, but what it ended up doing is reimagining how we were doing metadata in the first place. This crawl approach wasn't going to work.
So we ended up completely rearchitecting it to be stream first and be a deconstructed metadata platform, where, when the Oracle DBAs are pushing DDL changes to production, they're dropping in events over Kafka and that comes in straight into DataHub, or when a Kafka topic is getting provisioned, or when a Hadoop data set is getting registered, or a Hive table is getting registered. And so it made it much more easier for teams to know what their responsibilities are and what their contracts were with the rest of the organizations. Like, what does it mean to be a good metadata citizen? Well, if you own a system, it needs to produce metadata whenever it changes something.
And that led to, I would say the previous generation of DataHub. It has actually moved on since then, since Acryl formed, but the previous generation of DataHub was really event oriented, that was when we re-open sourced it back in 2020. And then 2021 is really when Acryl got started, and at this point Acryl and LinkedIn essentially have joined governance of the project. So we have, LinkedIn is an investor in us, but Acryl is the main contributor to the project. And we've been really stewarding the project, making a lot of contributions to it, and also bringing in a host of new contributors.
So a lot of big companies like Netflix and Pinterest and Stripe, PayPal, Optum, they're all not just using the project but actually contributing meaningful features back, and so that's been a great journey. And the community started out on Slack, and it was around 200 or so when we got started in early 2021, and right now we just actually celebrated 10K, so we just surpassed 10K members, which when we started was, for us, a dream goal, like, "Oh, if we hit 10, that'll be amazing," but it's been fun.

Eric Anderson:
What do you make of that community size? Maybe it means that the people who interact with the project are really involved. It's not like you have a lot of people who drive by and vote, "This is cool," GitHub star, move on. They see what you're building and then they want to be part of it. But maybe you have a deeper insight on what drives the engagement on the community.

Shirshanka Das:
Well, there's definitely a few common themes that emerge. First is the system, just installing the system and getting it to work isn't enough, but a lot of people drop in just for that. Like, "Hey," the usual troubleshooting stuff, like, "Hey, I installed it, ran into, I was ingesting this stuff and ran into this issue." So that's definitely a large majority of what people are coming there for. But then what they stay for is actually interesting, because for a lot of people, once they stand up the product and they actually see that, "Yeah, I can deploy this thing, and I can ingest a bunch of stuff pretty quickly," they then start asking the second order questions like, "Wait a minute, what do you do with this thing? And how do I deploy it? Who uses it? How do I get it to the kind of adoption that I read about on the blogs?"
We know that Airbnb, LinkedIn, all these companies got to amazing amounts of daily usage of something like this. How did they get to that point? What were the strategies that they used? How did we get to the modern data governance capabilities? Can I just keep doing what I'm doing right now, get my central data governance team to come in and click some buttons and annotate some columns? And is the tool going to solve all these problems or do I have to change how I'm doing data to take full advantage of what this tool enables? So that's really what leads to a lot of very interesting conversations around modern data stuff. There's governance, there's observability, and then there's also just productivity. And that, I would say, leads to a lot of very interesting things, and many of these people are actually then pushing features back or pushing ideas back into the project.
Netflix took a look at it and they liked it, but then they said, "Wait, we can't really adopt it until you've built these things, like the platform has to be completely runtime metadata model extensible." And we said, "Okay, why don't you join forces with us and we can collaborate and design this thing together with you and then we can build it together?" And so that's exactly what we are doing right now. And then, of course, that leads people to stay and build even stronger engagement.

Eric Anderson:
One of the things that open source maintainers have to wrestle with is what are the scopes and the bounds of the project? What do we say no to? What do we say yes to? And I can imagine that being especially true here, big community, kind of unlimited scope on things you could cover. Should we do lineage discovery? How far do we want to go on lineage? And so how have you dealt with that? Have there been tricky areas? Where have you come out and what do you want DataHub to be in the future?

Shirshanka Das:
It's definitely a very important problem that we've wrestled with, especially because this product, in many ways, fills the gaps between every other product out there. It's really about doing the things that these other tools are not able to do among each other. And so the possibilities tend to be limitless. Lineage tends to not be so much of a controversy. I would say the biggest two areas where we've gotten quite a lot of interest in building towards, and we've cautiously walked in that direction, and sometimes said, "Hm, not a great idea." The first would be just straight up BI, like, "Hey, I'm already looking at this table. Can I just visualize it right here?" So that's a common ask. The other one is access management. So a lot of these are essentially next steps after finding something. So you found something, what are you going to do next as a data practitioner? You're probably going to request access to this thing, so that you can then go query it or access it or do whatever you were planning to do with it.
And the way we end up deciding is obviously, it helps that we have limited resources and limited amount of design bandwidth at the very top. Like if you look at the main folks driving the project, it's not like we can completely parallelize all of the thinking. And so that helps, but also from a focus perspective, we think that our goal is really to help people get to where they need to get to and not have to change how they work with data necessarily. It's just about reducing the friction they have in working with data. So anything that helps us reducing the friction that they have in accomplishing a data transaction, if you will, where a data transaction could be, "I want to get access to a data set," or, "I want to be able to query a data set," or it could just be, "What is the data I need to do my job?"
So the way we build is always using an extensible mechanism so you can always connect to the system that is providing that functionality for you. We like to participate in essentially a composable data stack, which means, for example, if you have a data quality tool that you're using, you can plug it in. If you've got an access management tool that you're using, you can plug it in. And those helps us build the right discipline around what the interfaces need to be and what the plugin points need to be. And then over time, the community gets to decide if certain parts of this makes sense to be part of the batteries included section of the platform or not.

Eric Anderson:
How did you go about deciding to build a company around the project? I think some open source founders almost found the two simultaneously. You started this in 2013 and I think you didn't incorporate it until a few years ago. What was the catalyst for that?

Shirshanka Das:
I would say the pandemic definitely had a big reason to do it, it's a strange occurrence, but my life at LinkedIn had been extremely productive for the entire time I was there. I was always building something and at the same time creating a net new thing in my whole time there, so there was that hamster wheel of innovation that I was always on, and that kept me going for a really long time. But 2020 is when I was able to take a little bit of a step back, because the pandemic hit, we were all on Zoom. I happened to actually lose a parent at the same time, so I anyway took a little bit of time off to reflect on things that I wanted to do, things that drive me. And when I came back from some of that self-reflection, I felt like I needed to do something of my own.
And I also realized that LinkedIn's data team is not going to fall apart if I leave. We have such overinflated understandings of our own self-worth when we are at a place for a really long period of time. I used to feel that same way, but stepping back in 2020 because of the pandemic and a little bit of a break that I took definitely helped me realize that I could walk away and not worry about the team doing well. So that led me to think what is it that I want to do? What is the change that I want to see? And I continuously kept coming back to this thing. The one thing that annoyed me the most about how we were doing data was that we were siloing too much in how we were hyper solving certain problem segments. Data quality and data governance and a few of these other things were being pursued as independent ventures.
And having seen the benefits of solving this using that single metadata platform to perform that consistent graph made me feel like there was a better way to do things and we could have, as an industry, compounding benefits if we did it in this way. My co-founder, Swaroop, who I had worked with really closely at LinkedIn for many years, in fact, the database that I built there for the online side was actually something that I built along with him, had gone on to lead data at Airbnb after that, and he was leading search infrastructure and knowledge graph stuff there. And Airbnb had also a legendary data team and cloud native data architecture, very different from LinkedIn, LinkedIn was very on-prem.
And so we got to talk and turns out he had been noodling on similar ideas and had come to a very similar conclusion because he had run a bunch of initiatives at Airbnb, like cost attribution and things like that, and had realized, if only we had all the metadata in one place, I wouldn't have to solve this problem nine times. And so we decided to combine forces and build a company around it. I like to think about it as getting the best of LinkedIn's data in for platform talent and getting the best of Airbnb is product ethos and ability to build delightful product experiences. That's how we started. Of course, we have a team that spans the globe right now and has exceptional people from all kinds of companies.

Eric Anderson:
It sounds like the dream team. I always think you want to have someone with a high degree of trust, someone you've worked with before, but also has a very different network of resources to draw from, and you hit the target there on that one.

Shirshanka Das:
It definitely feels that way.

Eric Anderson:
There's a debate, with cloud and SaaS being dominant, is there an advantage to being open source anymore? You can just create a SaaS product that does more or less what the metadata platform does. How have you and your customers arrived at the value of open source?

Shirshanka Das:
That actually does come up quite a bit in how we think about what we put out in the DataHub project and what we keep commercial. And also when we talked to our customers and ask them, why did they choose us? And I, of course, I'm a builder, and so I have a very skewed perspective on a lot of this stuff, because I want to see the code, I want to know that the thing that I'm going to be using, I can actually understand how it's built.
But even for organizations that are not built like that, we definitely see the desire to not be locked in, have such a strong resonance. Because, like I said earlier, a lot of the things that you put in DataHub are really your company's crown jewels, your semantics around, what is this thing? How does it look? How does it relate to other things? Besides, of course, getting all of the metadata in and all of the operational metadata in. And so for a lot of our companies, they really want to have that ability to work with something that's going to be an open source standard, that's going to have longevity beyond even the one vendor that they're starting to work with.
The other thing that I've seen come up repeatedly is the fact that we are open source allows a few of our customers, not all our customers, but quite a few of our customers, to actually move the project forward in the direction they needed to go. For example, PayPal wanted access management to be a thing, and Acryl, as a smallish startup, basically said, "Great idea, but we are busy doing X, Y, and Z in our roadmap, which you also need, but we could partner with you, and guide you through that implementation, and you could just contribute it to the open source project." And they did exactly that.
And now the access management or the access request capability is now in open source DataHub and it's also in the Acryl cloud product. And we've had multiple customers actually do that. A lot of customers work at the edges, so integrations are a huge part of the metadata complexity problem, being able to connect to pretty much anything you have in your stack. So we have a lot of our customers actually contributing those improvements back and that helps the next customer, so we see a lot of advantages of that pattern.
But then even deeper inside the core of the product, we've seen a few of our customers actually contribute stuff back, and that makes customers feel a lot more in control of their destiny. We've heard stories of customers essentially being told, "Oh, this is a good feature request, but you have to wait six months or a year before we can put it on our product roadmap." Whereas in this case, they're able to actually make those changes with our consultation, but without having to wait for a ton of product development from our end. So that's definitely given us a lot of velocity advantages and trust advantages.

Eric Anderson:
Yeah. What's the future hold for Acryl and the project? Or maybe shifting gears a little bit to something more forward-looking. If people hear this and want to get involved with either the company or the project, how can they do that, and what would you have them look forward to in the years to come? And maybe, actually, let me overload this question with one more idea for you, we haven't talked about AI and generative AI yet. I think a lot of people are tempted now to pivot the roadmap more around generative AI, or AI in general, and I can imagine a data catalog or a metadata platform being tempted to do that. Where have you come out and, do I stay true to vision, or capitalize on the opportunity at the moment?

Shirshanka Das:
Yeah, so that actually ties into DataHub's positioning and its future as well. At LinkedIn was one of the interesting things we had done with DataHub was pointed it not only at data and BI style problems, but also at AI problems. So LinkedIn's entire MLOps infrastructure was actually built on top of DataHub. Model reproducibility, model discoverability, feature engineering, metadata, all of that was stored and represented in DataHub. So it was actually not at all a surprise to us that when we looked at the emergence of AI and the hyper-focus on, "Well, let's just do AI, everyone, right? We have to do AI." Most of the teams get stuck on, "Wait, what data should we use? What is the semantics of this data? Can I actually build my model on top of this, or can I build my prompts on top of this? Is this the right trust signal?"
And so in terms of our future, we absolutely see ourselves supporting the emerging AI stack. It's actually one of the top requests, both from the community and our customer base, to index and store and represent ML models and features and all of these other AI assets in the same metadata graph, because these are all connected, a metric and a feature, and these are all connected. And you want, in fact, even more understanding of, why did this model perform well? And what was its performance over the last year? And is this still in production, or is this something that someone tried and tossed away? So we absolutely see ourselves supporting the emerging AI stack. It doesn't feel like a pivot at all. In fact, ML models and support for the Google knowledge card stack was actually added to DataHub in 2021. So we're just starting to lean into that muscle because people are pulling that stuff out of us more now.
But in terms of how we think about DataHub, it's really cementing and solidifying its foundation in the industry as the de facto metadata platform, and starting to see more control plane use cases pop up, where people are able to register their definitions of data products and they're able to actually see those data products get deployed into production using DataHub as the definitional layer. And actually it's basically taking DataHub as the platform and then building opinionated experiences on top of it, that's essentially accelerate time to value, they accelerate time to collaboration, they accelerate time to getting your data under your control by having friction free governance experiences and things like that. So it'll continue to be that symbiotic relationship, which is, as DataHub the platform gets better and more capable, AcroCloud, the opinionated offering, just gets faster and better.
Since you asked, how can people engage with the project and learn more? Honestly, best way is just join the Slack community. It's very simple, just go to slack.dataproject.io and you'll get a quick form and then you'll just get signed back in.

Eric Anderson:
Great. I think on the AI stuff you were talking about, it seems to me there's three levers to good AI, and one is the algorithms. People talk a lot about transformers, or this or that. But the other is volume, and I think that's honestly what's driven a lot of the improvements of late, they've just... OpenAI has just ramped up the data size in ways we never really imagined. And then the third being quality, and I think that's the third lever that nobody's quite touched yet, and that everyone's waking up to, is like, we don't need 70 billion parameters as much, if we can dial up the quality. And I think both the volume, managing quality at scale feels like it could be a metadata platform sweet spot, I don't know if I'm thinking about it the right way, but maybe the market's moving in your direction, Shirshanka.

Shirshanka Das:
Absolutely. We see our role as dual. First, being a ledger of all activity that's happening that's of interest. And the second, of being the importance meter, so being able to give you the important stuff that drives the value on top, like facts and then insights, if you think about it more simplistically.

Eric Anderson:
Super, thanks for joining us today for the discussion, and congrats on all you've done, but also thank you for this awesome project. I think one of the cool things about doing these open source conversations is we get to appreciate the fact that you've given something to society.

Shirshanka Das:
Yeah, it definitely is one of the biggest things that drives me. Anytime someone comes in and installs the project and says, "I love this project, this was so amazing," and then they say, "But..." And then I have the small problem, I'm like, "Okay, that's validation right there, because at least you love the project already, and then you have small problems." But yeah, it's been a great journey. Honestly, it keeps a lot of the engineering team motivated as well. We actually do on-call rotations where the entire Acryl team actually is on call for the community, and we do community marathons where we stay on a Zoom call for six hours every month, and so that kind of stuff, the kind of validation and the love you get from the community, it just keeps everyone going. So it's just super virtual cycle.

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.