Eyar Zilberman is a co-founder and CPO at Datree. Datree is a CLI tool that supports Kubernetes admins in their roles by preventing developers from making errors in Kubernetes configurations that can cause clusters to fail in production.
In law school, Eyar researched open-source licensing, fell in love with the technology, and became active in the development community. He has always been fascinated by the concept of open source and how it enables developers of all expertise levels to build applications and automate processes.
In this episode, Eyar talks about why people are creating open-source projects, the reason building in the open for a company makes sense from day one, and why stars, licenses, READMEs, and tags on GitHub projects are important.
Links:
- Datree
- Follow Datree on Twitter
- Docs
- Eyar Zilberman: Twitter | LinkedIn | GitHub | Dev.to
- Kubernetes
Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!
Give us a follow: @PolyglotShow
Transcript:
Ben Greenberg: Hello, everyone. Welcome to another episode of Polyglot. My name is Ben Greenberg. I'm a Lead Developer Relations Engineer here at New Relic. And today, we are joined by Eyar Zilberman, who is the Chief Product Officer at Datree io. Hello, Eyar.
Eyar Zilberman: Hi, Ben.
Ben: It is so nice to have you here.
Eyar: Yeah, I'm excited.
Ben: So tell everyone a little about yourself. Who is Eyar Zilberman?
Eyar: [laughs] I'm still trying to figure it out by myself, but I will try. So my name is Eyar, and I'm leading the product at Datree, also co-founder. And what we're doing at Datree is basically it's a CLI tool, open-source, of course. And this is also what we're going to talk about today. And it's helping developers and DevOps people to prevent Kubernetes misconfigurations from reaching production.
And it's doing it by actually checking the different configuration before it's deployed into your cluster. And also, I'm leading the local GitHub community here in Israel, which is the biggest in the world. I don't know if you know that, but here in Tel Aviv, we have the biggest one. And some fun facts about myself, I love goats. That's my power animal.
Ben: Everyone needs a power animal. I would not have known that goats would have been your power animal, Eyar. That is fascinating on a couple of levels. First of all, I love how you said our product is open-source, and you qualified it by saying, of course, of course, it is open-source. So we're going to get to that in a moment.
Why is it, of course, for you? Why was that such an inherently obvious choice for you to make at your company? And how has that worked so far, building in open, in the public, building and learning in public, and creating an open-source tool? But before we get there, how did you end up creating the largest GitHub user community not only in our little country of Israel but in the world? How did that happen?
Eyar: Well, it's actually funny. It's exactly like open-source. It's happening for a need. So I had some questions about how to build a GitHub application that you can put on the marketplace. And I didn't find the knowledge online. There wasn't any YouTube tutorial or stuff in the documentation that helped me figure it out. So I started to find people that can help me. And I was surprised because every time that you have something, you're going through your local meetup community, you know, if it's AWS, CNCF, or everything else.
And with GitHub, I was surprised that so many people are using GitHub, but there isn't any local community. So I decided this is a challenge that I actually want to take on myself. And I started the community. And on the first meetup, we had more than 100 people showing up. So I think it was a clear case of product-market fit.
Ben: [laughs] First of all, I'm not surprised at all about that. For those of us listening to this podcast episode, I first met Eyar now going back several years ago. We had a lovely coffee together at a coffee shop outside both of our mutual workplaces. And your drive and passion was already so evident in that one meeting. I'm like, this guy is a person we need to put ourselves close to because he's going far. So the fact that you created the largest GitHub community not only here but in the world is testimony to that.
And I think the kernel of it, though, where you said, there was a need, and the need became evident as I spoke to more people, and they also had that need. And together, we created something. That kernel led you to a meetup, but that kernel of that expression of there is a need, and we need to solve that need can also be an excellent motivation for creating open-source projects.
Eyar: You're totally right. So let's talk about why people are creating open-source projects. And so I will put my project out again, and we start with the why. So why are people doing it? So I tried to think about it and research a little bit. And I found three main motivations that are helping people or causing people to actually open an open-source project. Because let's face it, that's a lot of responsibility to open an open-source project.
So first, maybe you just want to build your own brand. It's a really nice way, a good line to your resume. Let's say you just finished school, and you want to get some experience, hands-on experience. So you can open an open-source project; maybe you get some people to actually use it. And the next job application that you're going to submit will also have this on your resume, and it will look really, really good. For example, when we are hiring people for development positions, this is something that we're looking for. Are you part of the community? Are you contributing code? Maybe you have your own project that is used by the community, something that is a huge bonus when you're evaluating developers.
Something else maybe it's your business, so Datree, it's my business. And, of course, I love open-source. And for sure, it was meant to be an open-source project. But in our space, when you're doing something for developers, especially for DevOps people, engineers it has to be open-source. This is the standard today for every dev tool.
And the third reason that I think that a lot of people will identify with is actually, maybe you have a passion for something to solve a problem. So for me, for example, I had a project it was for creating a backup for a Jira instance. A lot of people were using Jira by Atlassian and were using the cloud version. And apparently, there's no way to create backups to what you have on the cloud. And I looked for different solutions for that, and there was nothing out there that's supported by Atlassian or by Jira officially.
So I just used some API calls, glued them together, and I created some kind of application, then doing it on a priority sequence. And there you go; it's an open-source project. So it was something that I needed for my own reasons. But each one of us we're coders, so every time that we see a problem, we're trying to solve it with code, sometimes over-engineered. I guess you'll also have your own examples.
Ben: I think what you just articulated makes so much sense, and those different gradations, if you will, of why to get involved in open-source feed into each other. So if you are somebody who needs to advance your career, as you said, open-source becomes a fantastic tool to advance your reputation and your recognition as a developer when you get involved in projects, when you get involved in community.
When I was just starting out in code as a career changer, I was told that advice. And they told me, "Get involved in open-source. Get involved in GitHub." But then I had a hard time thinking what I was going to do until I was faced with a problem. And then, the problem became the motivation when I had to solve something for myself and automate it. So whether it's solving daily health forms, I needed to fill out for my kid's school and automating those daily health forms.
Or I was working on a project across time zones, and I wanted to know what time was it for the person I was collaborating with. I created a GitHub Action so I could ask what time it was for the person, and then GitHub fetched their location and got with time API and got me the time for that person where they were and helped me understand whether or not they're in the right time zone to ask them something or not. Those personal motivations help drive it, and I think that is 100% spot on.
But what I think is really interesting for our listeners and for us to talk a little bit about is how does building in the open for a company make sense? And when do you start doing that? When do you take your product? When you take your tool and say, am I going to from the very initial iteration begin building in open? And meaning that it's going to be all in the open-source, and it may be messy in the beginning. Or am I going to first polish it up?
And we've seen different attempts from different companies, and they decide to release it as open-source later. And you can only imagine all of the engineering work that went to making it look good first before they released it as open-source. Or do you start from the beginning when it's all messy and dirty, and you're still figuring it out? And you have a lot of different...you're pushing up code that may not look so nice all the time because you're just trying to get it right, and you're iterating in your early steps. When do you start building in the open? And why does it make sense to build in the open?
Eyar: So I think it's really related to what you're trying to do and which interest you address. So again, like I said, if you're doing something for engineers, it has to be open-source from day one because you want them to see the code because this is how they trust the project that they're using.
Today it's a little bit weird to see projects that don't have open code because this is the standard. It's really different if you're going to build a tool for marketing people. And if you're building a tool for marketing people, for example, I don't know, you have Zapier. It's not open-source, and it's totally fine because marketing people are not familiar with what is GitHub. So I guess they don't really care about it.
But again, there are pros and cons for each decision if it's going to be open-source or if it's going to be closed source. I think the question that you need to ask yourself when you face this dilemma is, what am I trying to achieve? And will doing it open-source actually help me do it? Or maybe it can actually have some bad impact on my business.
Ben: You decide from the very beginning, let's say to build as an open-source project because that's the standard for engineering dev tools today. You start from the very beginning. Before you start pushing code to the repository on GitHub or GitLab or wherever you're hosting, what are some of the things that you should do to get the repository ready to be widely available for the community, to be accessible to the community?
Are there things that you do as a preparation for that code? The ways you set up that repository to make it more usable and more user friendly for those from the open-source community who don't work at your company but who might want to browse the code, maybe raise an issue, maybe even offer a pull request, maybe they want to contribute code. What kind of things do you do to the repository even before you start really pushing code in there?
Eyar: I think that actually writing the code this is the easy part because, like I said, we're all engineers, so writing code is not something difficult for us. Actually, doing all the things around it and to make sure that people will understand how to use it and will use it is actually the hard part.
And it sounds so obvious like, why should I write something if no one is going to use it? But the fact is that majority of projects that are on GitHub; no one is using them. I ran some numbers to check it out. And it looks like you have more than 30 million repositories today on GitHub, and only, listen to that, only 4% have more than ten stars.
Ben: What does having less than ten stars tell you intuitively?
Eyar: Actually, it can tell us a lot, and it can tell us nothing. [laughter] So it's a good indication if a project is popular. If it has zero stars, I guess no one is using it, but it's not the only indication if it's a good project. But it can be a really good indication to tell if it's a popular project, if a lot of people are using it, if it is a community-facing project, and so on.
So it's a good indication to get started. Because yeah, there are many other factors that you need to consider, like when was the last commit to this project and how long it's taking them to actually solve bugs, and a lot of other factors. How many pull requests have opened? How many pull requests are closed? What is the size of the repository? A lot of factors.
But again, I think the stars are a really good indication to actually tell you by a glance if this is a project that you should consider using or not. I'll tell you what, when we started our project, we started with zero stars, [laughter] of course, like everyone else. But today, we have more than 5,000. And I was surprised that the code is pretty much staying the same. But if we change a lot of stuff around it, and this is what drove the adoption and what drove more stars to this project.
So some important stuff when you're getting started, and this is like the mandatory stuff. I'll start with the mandatory stuff, license. I guess not a lot of people are familiar with why you need to have a license or why to use a license. I'll just give it in a sentence. But basically, a license is a way for us to understand if you can use the code and if you can use the project freely or not.
Ben: And how you can use the code.
Eyar: And how you can use it, exactly. And if you don't have the license, by default, you can't use it. Although you can see the code, you can't use it. And this is the legal hat that I need to put for a second and give this disclaimer.
Ben: You have so many hats.
Eyar: Yeah, [laughter] actually, I don't know if you know that, but I actually finished studying law.
Ben: I'm not surprised.
Eyar: Yeah, that was my degree, studying law.
Ben: Engineering, law. You're just creating your own startup basically at this point. [laughs]
Eyar: Yeah, one-man startup, exactly. So a license is really, really important, and it's important to put the right license. I'm not going to expand about how to choose a license because there's so much information about it. Just Google license for GitHub, and you have all the information about how to choose a license and how. And once you have the license, people will see the project and understand that they can use it.
The second thing that is important is to have a contribution guideline. Because if someone will find your project cool and will want to actually submit a pull request, you want to understand the guidelines, how it should look like, what you will accept, what you won't accept, how the commit message should look like, what is the day for doing a code review, so on. All that information it's important for people to know.
Something that was really surprising for us that we didn't implement it when we started, but when we crossed the 1,000 stars benchmark, we actually introduced it, and it was amazingly effective. So we had a lot of issues, but we saw that people are not taking them. But we knew that people are using the product because, like I said, we already had like 1,000 stars, and we had the community around it.
So we knew that people were using it, and we knew that people are loving it. But we had issues, and no one was taking them. And then someone told me, "Hey, there's a problem. Think about the person that wants to submit code for your project for the first time. And it's a big project right now, and they don't know where to get started. You need to tell them which issues are good first issues."
Ben: The tagging of the issue.
Eyar: Yeah, exactly, the tagging. So we started to tag them. The second that we tagged the issues, they disappeared because people took them.
Ben: So, not having the tag became a barrier to entry.
Eyar: Exactly, exactly. Because think about it, you see a Golang project. It's an enormous project with 1,000 stars, and you're afraid to actually go in the core of this project and actually start doing stuff. You want to do it with baby steps. You want to change small stuff, but you don't know what is a small change. So you start with everything that is tagged as a good first issue. After we did that and we saw there's a lot of impact, we actually changed the way that we're opening issues.
When we're opening issues, we're trying, especially for good first issues tags, we're trying to explain exactly to the person that will take it which part of the code they need to change, where they need to touch in order to submit this pull request. We're trying to help them as possible to guide them because the motivation is there. People want to contribute code. You just need to help them get started. So that was really important.
And the last thing that is the most important thing is the README. So the README this is actually the cover of your project. This is how people will decide if they want to use it or not. Think about README in plain text with three sentences and compare it to a fancy README with badges and images, and examples. I can promise you that you will actually try to read the second one trying to actually investigate if this is something that is interesting or not. While if you see a project with three lines in plain text, they didn't spend too much time on the README; why should I spend time reading it? And you can miss something amazing.
Ben: I think those points are so crucial. And for a lot of people getting involved in creating an open-source project, whether it's an open-source project for a company or their own personal project that they want to get people involved in and excited about, they often forget about those steps, whether it's the basic legal fact that without a license, no one can use this code. They can look at it, but they can't use it. So you need to license, the contributing guide, how to contribute, what areas you're looking for contributions in, and what type of contributions you're looking for, and how to submit the contributions.
And then tagging issues, and you're totally right. We often tell people to get involved in open-source. Everyone should get involved in open-source. But then you come to a popular repository, a popular project with thousands of stars and hundreds of pull requests, maybe more than hundreds, maybe even 1000+ issues. And people are really engaging in them, and you're brand new. It can feel very intimidating to enter into that project.
So tagging as a good first issue, creating pathways, helping people identify where the code lives, where the change might happen. I think they are all ways that you can help make it not only welcoming for the veterans of the project, and continue sustaining the welcoming for the veterans, and making it a place they want to stay in, but also welcoming for those who are just coming in.
And you have to always wrestle with both of those at the same time. How do you keep it a place that nurtures those who are continuing to provide support to the project and who are part of the community while also not alienating and being a welcoming place for those who are brand new, whether they're brand new in the project or they're brand new in the project, and they may also be brand new in code? And they see your project is something that's really interesting. And maybe this is the place where I want to finally get involved. Do you have a docs issue that they could jump in on? Is there a testing issue they could jump in on?
I often found that getting early developers writing testing is a great way as an entryway into a project because you get to learn the project through writing testing, and testing teaches you the behavior of the project so those sorts of things. I think you're totally spot on about getting people involved. And how has that worked for Datree? So it sounds like you went from zero stars to thousands of stars. It seems like it's going pretty well overall, if I'm understanding correctly.
Eyar: Well, it was 1,000, and now it's more than 5,000. But yeah, [laughs] doing all this infrastructure to make sure that people will feel comfortable to be involved in the community that you are creating is supercritical. But again, it's a startup, and your open-source is also a startup. And just like that, it's always important to prioritize stuff. So we talked about what is mandatory. Let's talk about stuff that is less mandatory, and people actually tend to think that they are critical. So you will be surprised less critical is code coverage and unit test. [laughs]
Ben: Shocking. That's shocking.
Eyar: I know, I know, but I'll tell you why. Because if we're aiming to do something that adds value and we want to have the community join us in doing that, like you said, testing is a really, really good place for new contributors to get started. So this is something that you can put aside because it's taking a lot of time. So I'm not saying do zero tests, [laughter] don't check that it's actually working. Do the bare minimum but also leave some room, not to make it 100% code coverage but give some room for people to actually get involved. It will save you a lot of time.
Ben: I think that is such a brilliant insight that you intentionally leave gaps, not in a bad way and in a malicious way. You have coverage of your code, but you're not necessarily covering every single detail with 100% code coverage in order to provide the space for those who are just entering into the project, provide them an easy avenue to get involved. And testing happens to be one of the easiest ways to get involved, and it's a great way to learn the project.
I think that's fantastic and especially when you're talking about a project which is like Datree, which is both so essential because Kubernetes configurations can be a nightmare for so many people, figuring out your configurations for your Kubernetes clusters and the deployment options. And the complexity can scale dramatically. And that scaling of complexity, the more the complexity, the more potential problems there are.
But at the same time, that complexity can also be overwhelming and can be almost intimidating as well. Kubernetes, as an area, can be very intimidating. Have you seen in your role and at Datree, and it's part of open-source, that not only have you made your product more accessible by being open-source and more genuine, more authentic to the developer community, but it has helped also get more people involved in Kubernetes? Because your project, in some ways, can be seen as a gateway into understanding and having a more thorough involvement with your Kubernetes configurations and understanding what goes wrong and getting more insight in all of the vast and complex world of Kubernetes.
Eyar: Yeah, of course. So because our tool is actually providing some kind of, let's say, a guardrail for someone that's getting started, and so we can actually try Kubernetes without making fatal mistakes. So essentially, [laughter] I think getting started. And like you said, Kubernetes has so many setups and knobs that you can change, and just missing a character or something can actually cause total failure. [laughs] If something is not configured correctly, nothing is working. So Datree is a really good way to actually getting started with Kubernetes.
But the fact that it's open-source, it's also created something interesting that we didn't consider, but we're really, really proud it's happening. So it's helped people to actually be engaged with our own open-source. But it's actually created a community around our open-source, which we saw people actually creating their own projects that are relying on our open-source.
I'll give you an example. So someone created a VS Code extension that is relying on our project. So we didn't add this integration. So he took Datree, built a VS Code extension. Behind the scenes, it's actually our open-source, but it's a project that he created. Another example, so someone created a Tekton plugin, which is really common when people are using Kubernetes. And someone else created a GitHub Action for GitHub.
Ben: So the ability of it to be open-source one of the things that it lets happen is that it accelerates the adoption with all different types of other ancillary products and projects that people are building on top of your project. And it makes it that much more relevant for the developer community.
Eyar: Yeah, exactly. And something that I really enjoy doing is actually looking for people that are using Datree in the CLI. So it's really easy to do it. You just write Datree; you look for YAML files. And just to see the number of projects that is rising that's using Datree in the CLI is so satisfying to see that people are using it and enjoying it. And it's implemented in their workflow exactly like we intend.
Ben: That's one of the amazing things of open-source in general. You can search across and see, oh, this project is being used in all these things that I didn't even imagine would have been used. Or they were on my roadmap, but we never got to it yet because we're doing 30 other things. But this obviously was a need for this developer or this project. And they built it for us, and they put it on the open too. And now it's being used by the vast community. It's unbelievable. It's amazing. You're totally right. So it sounds like it's working pretty well for you.
Eyar: Yes, yes. Yes, it is.
Ben: [laughs]
Eyar: But I also want to give some tips to other people that are starting open-source projects.
Ben: We'd love to get those tips. I'm sure we want to hear them. Go ahead.
Eyar: So we talked about how to write it. We talked about what should be included, what you can actually skip. And I think that another really important part is actually how to market it, how to make people hear about it. And I think this is, again, something that people tend to skip. And it's not magic. It's not once you click on make it public everyone is coming and making a star and starts using it. It's not like that. There's actually some elbow grease, work that needs to go into it to make people hear about it.
So again, I'll give a disclaimer; some projects are so amazing. And it's happening that sometimes they are going viral, and you don't need to do anything. But for the majority of projects, including ours, by the way, we needed to do some effort from our side to show to the community that this is something that we created, and you can actually use it. So I do want to give some best practices for that.
So I think it's not that hard because if you think about it, we are the audience of something like that. So I thought about myself. I thought, where do I find my own open-source projects that I'm using? So I know that I find them on Hacker News, on StackShare, Reddit, Slack groups, Twitter, newsletters. And these are exactly all the places that we went to publish and to announce when we created Datree. And it's really, really important to always think about it. You're, in a way, the user of your own product. So you can think about where you find other open-source projects. And this is how you need to market your own open-source.
Ben: So the question I have for you on that, and I think you're totally spot on, is how did you manage to do that in a way that felt natural? So again, putting ourselves in that perspective. And I'm looking through my subreddits that I like to read, and I come across material that feels very marketing. I may just walk right past that. But how did you make it in a way that felt like it was something I, as a developer, would want to look at?
Eyar: Super easy. Don't give a marketing guy or woman to do it.
Ben: [laughs]
Eyar: Do it by yourself and write it like you want to read it. Every time that I'm writing something, I'm trying to read it again. And I'm saying, will I use it, or will I say what a bunch of BS?
Ben: [laughs] Fill in the word, right.
Eyar: And I always try to write stuff that I want to consume, and I want to read by myself. So I will never write something that is high-level marketing fluffy with no content and big buzzwords with no examples. So every time that I'm announcing something or every time that I'm writing about something, if it's a Hacker News, or Reddit, or whatsoever, I'm explaining exactly the use case. I'm explaining why we built it.
I'm actually getting really technical about how we did it because people like to geek out about the technology itself. So we explain exactly how we decided to do it. Sometimes we actually explain why we decided to do it in a specific way and not in another way. Why did we decide to use Golang and not Python? And again, I'm trying to think about stuff that I want to read. And this is how I write the announcement.
Ben: That is so important, and I can imagine it takes an extra layer of thoughtfulness. Because when you're writing something, you also have to then put yourself in the perspective of the person who's reading it. And so many times, we're in the mind of writing, and we don't take the extra step to say, okay, let me read this through the no-BS factor and look at this from my personal perspective. And does this actually read okay, or am I writing something which is going to be put in the metaphorical garbage the second that I look at it?
And a lot of times, we don't take that extra step. So you're saying it's crucial. It's pivotal to take that extra step and think to ourselves, am I actually going to be wanting to read this? And if not, I need to go back and rewrite the whole thing.
Eyar: Exactly.
Ben: That's amazing advice. I think that is...for those of us who are most interested in getting people to even hear about our open-source project, a lot of us know we go to Hacker News, we go to Reddit, Twitter, newsletters, but it's how you phrase it. It's, do I want to read it? And more than I'm writing it, but do I actually want to read what I'm writing? I think it is so important. And that tip is really, really, really crucial. Eyar, thank you so much for your time today. I think this has been a wonderful conversation. Where can people find you out in the world?
Eyar: Everywhere. So LinkedIn, Twitter, and GitHub, our own project, open an issue. I will also drop a link for people to check out, and they can ask any questions that they have about how to do open-source or how to market their open-source. And I will be more than happy to share from my experience.
Ben: From first-hand knowledge, Eyar is very accessible for everyone. He will respond to you. Thank you so much for taking the time. We will post those links in the show notes. Thank you so much for joining us on Polyglot.
Top comments (0)