In episode 6 of Swimm Upstream, Host Tom Ahi Dror speaks with Liran Tal about open source projects - inspiring education and empowering developers to increase awareness of application security. Liran is Director of Developer Advocacy at Synk.
Hello, everyone, and thanks for joining us on this episode of Swimm Upstream, a podcast devoted to engineering team leads and dev tool enthusiasts. I'm Tom, co-founder of Swimm, and today we're talking with Liran Tal. Liran is Director of Developer Advocacy at Snyk. And has more than 15 years of experience as a software developer and engineering manager in various leading companies and as a startup founder. He's also a core contributor and open source enthusiast, a GitHub star, a published author, and more. Hi Liran, we're excited to have you on. Thanks for coming to speak with me today.
Thank you, Tom. I'm excited to be here as well. Thank you for having me.
Yeah, so we have about 15 minutes and lots of questions. Let's see what we can cover. Let's start with this one. Liran, at Swimm, we take coffee very seriously. Probably too much.
As you should.
So yeah. So to start things off, if you could have coffee anywhere, right now, where would it be?
I got recently reminded of a place I was taking a breakfast off in Barcelona. It was a nice little, really cozy small, you know, coffee place outside of the tourist zone. And I was there for a couple of days, you know, community stuff, medium conferences, and some customer meetings - just before COVID hit. So I was actually thinking about this gathering a couple of days. Like, wouldn't it be nice if travel went back in and we could, you know, take those moments of breaks in different cities.
That sounds magical. Yeah - yeah, I missed that feeling too. So you know, this past year and a half, and you mentioned this - have been mostly focused on adjusting to the realities of COVID 19. What's one thing you learned to live without that surprised you?
Okay, I'm gonna regret saying this because I miss it so much as well. But I kind of like learned to live without this - this is, you know, pizzas and fast food or junk food. You know, in a COVID times - so I think it was quite after it started around May 2020 - I got myself a smartwatch, you know, for like health, fitness tracking stuff like that. I noticed I was, you know, quite a bit, you know, overweight and all of those stuff. So I started, you know, paying more attention to this stuff. You know, and today, like the best meal of the day for me is basically the salad that I make for myself at noon. And I have even refused, like eating outside - I’m making this only for me. So, but I missed pizzas. This is, you know, something I get from time to time. I eat that, but I miss having this more often.
That's commendable. I believe I've started eating more pizza since COVID. So that's quite an achievement. Okay,
So Tom, what do you think when all of those meetups rejoin, and then pizzas are going to be blasting off again?
Yeah, pizzas and beer. Let's hope. Okay, so, Liran, could you please describe what you do at Snyk without using your title?
Yeah. So I would say it would be about, you know, inspiring education and empowering developers worldwide, right? About application security, and myself being committed to making them really successful at it. If I had to, you know, without using that title, this is what I would focus myself on.
Would you - do you like the word evangelizing? Or, you know, is that used too much now?
I think evangelizing is - I don't know if it's used too much. But I think it's - notice I haven't said Snyk here, right? This is not about Snyk - it's about application security. So you know, whatever works, and it's not about, you know, the product features and all of that. It's about actually listening to what is helpful to developers. How can they be better? What do they need? What you know, what are the problems you’re having? Is it too much noise? Too many alerts? Do they need help triaging vulnerabilities and fixing them? So this is more about understanding that, giving them more knowledge. And you know - I started with inspiration first, right? I would like to inspire them, and this is - we may be talking about, you know, some of the open source projects later. But like also, I think the goal is how do you inspire developers to really like security to like join some security projects - to do something around this maybe they introduce a new like security link or something in their CIs and they feel really proud about it. These are the moments that, you know, I cherish a lot.
Okay, so sounds like you're trying to change hearts and minds and possibly even cultures. So that sounds amazing. So you mentioned open source projects, and it looks like you're very passionate about it. Could you tell us about open source projects you're involved in that you're most proud of?
Yeah, of course. I'm gonna pick a few of my own just because, you know, they have some interesting stories around them. And you know, they've been accompanying me for quite a bit of time now. So I'll start with a project that I called Dockly. It's spelled at sounds like Docker because this was basically, I think, the biggest project that I undertook to build a command line application that is a very immersive, like terminal user interface tool to manage your Docker containers.
And I'm gonna - I'm gonna the one regret I have about this is that I’m gonna do a spoiler here - is that this is, I think, the only project I probably have that, you know, in that scale that did not have any tests. Because I was like, you know, how do you write tests for like a terminal UI interaction, you know, pixels moving up and down, and so, and so forth. So there are some, you know, mechanisms and, you know, techniques to do that. But, I mean, Dockly has been a great, I think, cornerstone for me to, like, you know, this is how I also learned, you know, containers. I was like, how do you manage them. So I, you know, started, you know, building this out, and it became like, super popular. You know, Jess - Jessie Frazelle, you know, Jess has been kind of, like, you know, tweeting about it, you know, a couple of years back. And it, you know, really made some, some, some kinda like, you know, waves and interesting stuff.
But the part that I'm really, you know, most proud of is not, you know, me building that or something, but the fact that there were, you know, several contributors to that, that have actually, like, you know, continued your contributions throughout the years. Some of them refactor some of them added more things. And I love seeing that this is not, you know, people find, you know, in fixed bugs ad hoc, and you know, disappear from the project, but actually, no - they've been able to kind of commit and like what you're working on. And you know - do several commits, one after - time after time. So I'm proud that this has been like a good place for people to join, and they found it comfortable, you know, taking part of this community.
So new contributors to open source projects also have sort of like an onboarding process, right? Like you would see in a development team. I don't know how soon in the process of these contributors came in. But I wonder how is that process similar or different from onboarding to a new dev team?
Interesting question. I think there are like, probably levels of maybe like the, you know, the communication part, like the soft skills versus - I think probably the, I would say engineering wise, it's maybe like people are used to it. It's the same stuff - it's overlapping, kind of like concepts and concerns, they need to write code, you know, they look for the right structure, they have tests, and so on.
But what may be different is, you know, things like, you know, the expectation setting in the goal, right? Like, people come to an open source project, you know, their expectation and the alignment of what they want to do is completely different from that of, like, when you onboard someone to you know, company project or a day-to-day, you know, project. And so like, you know, maybe their goal is, you know, I just want to fix that typo and, you know, bye bye. I just want to add that feature or fix this bug because it's, you know, bugging me. And you know, that's it, right?
So the mindset is a bit different. And also, there's, I think there's kind of like this psychological, like, call it like the "I did it" effect, where, you know, I could be contributing to like Angular, but really just change the docs, because there's like a broken link. But for me, I have, like, I'm like part of the Angular community of like - have a committer somewhere in the history. And like, this is a great way for you to like participate in open source. So there's like a very psychological effect of, you know, ‘hey, I did it.’ And it's, I think it's massive when it's, you know, open source projects, just because, like, you know, you feel a lot - it's a lot easier to feel, you know, part of like a bigger community. Whereas, you know, if you fix something, even if it's major in Linux, and some backend, some frontend service, and the company is like, okay, let's, user story done, you know, completed - let's move on to the next sprint. There's a bit of a different effect there.
So you mentioned a lot of like visitors for a day as contributors, right? Like people coming to fix something specific that they need. And I think there's like this magical process that rarely happens, but is very important to understand how someone might start that way and then find themselves slowly or fast, you tell me, becoming a core contributor? How does that happen? Is that something you can control? Or is it just like fate or what?
I love that question. I don't think it's something you can directly control as like the maintainer or I - it depends, like the question - how do you, you know, question that. But I have a nice little trick that I'm going to share here. And that is when someone wants - when I see someone contributing to a project, my project that I, you know, I'm the maintainer of, the trick for me to get them in, you know, a bit more committed and you know it's a great way to also like, you know, build their portfolio and like, you know, their own personal brand and their confidence levels.
The trick is I, most of the time, I'll add them as a core member of the project. So if you commit, you know, to one of my projects tomorrow, Tom - anything - I'll probably get you to be a core contributor to that one. And I've seen it have a dramatic effect. You know, once you, you know, doesn't matter what contribution you did - you're just on it. At that point, there's, you know, your enthusiasm level, you're part of, you know, the mission is super high. And this is my trick. This is how I get people, you know, a little bit more engaged and enthusiastic about my projects. Don't ask me about the supply chain security issues with that one because it's a tricky one. But yeah, like, this is my way of welcoming new core members.
So it sounds like they also get a sense of responsibility, right? So if I'm a core contributor, maybe I need to get more people involved, maybe I need to look at some core issues and take responsibility for that?
Yeah, I think so I think like, it's, it's a sense of commitment, a sense of mission, there's like a sense of responsibility, accountability, like tracking the projects that you might like, you know, do some backlog. You know, kind of like cleaning and see, like what's going on, like old issues, maybe need to close them. And it's really, I think, a great way to like appreciate other members of the community that help you. Like, you know, you give them that stamp. They’re not just, you know, ad hoc contributors. You know, you're a part of the project. You know, sometimes they may not actually, like, live up to it, and do this whole full on maintainer, and that's okay. That's something that you know, as a maintainer, as well, like, if you're doing, you know, practicing this trick, you know, you have to accept.
So appreciation sounds very important. I'm guessing that people that are going through this process of becoming core contributors also want to see that you are investing in them, right? Investing in making it easier for them to get on board, investing and making it, you know, easier for them to interact as a team. Is that true? Is that important?
It is. I don't know how to make it easier for them to, like, interact with a team, I haven't managed open source projects to a scale of like becoming multiple teams with projects, and roadmaps and things like that. So it's nothing like the React projects and things like of that scale. But I do relate to the appreciation for it, like, when, when people contribute any sort of PRs to my project, I usually show that appreciation also beyond the repository. I'll go on social media, I'll tweet, you know, praising them, congratulating them, thanking them, the PR link, all of that.
I have in the past also, I think, for Dockly and for NPQ, another small project I actually got stickers and sent out. And the other thing I did was I need to do this more. You know, how do you have like those nice little gifts where this is basically kind of like, a block of wood, but something is carved in it? Like I printed the screenshot of Dockly to like one of the contributors, and sent it over. And it's like this nice little 10 centimeter block that they have,
And it's really pretty cool. I didn't have that. They have it.
That’s your second trick that you mentioned here today. That sounds really great. I wonder if other projects are doing something like that as well. Okay, very cool. So, you know, in this podcast, we like discussing knowledge sharing and developers technical onboarding, like we mentioned right now. And you bring two very unique perspectives, right, both as a developer advocate as and as an open source contributor. And in terms of developer advocacy. What kind of challenges do you face in building communication between Snyk and the dev community?
I would say it's probably several levels. And engagement, I think for security is - if you think about it - like security is mostly invisible for generally everyone. Because like, you know, of course, until you get hacked or breached, or you know, you leak data, that's where like, Hey, I care about security now. But you know, until that point, which I hope like no one goes through this kind of like incidents. But until then, like you don't really like care about it, right? It's kind of like invisible. Whether you have security or you don't - kind of you're not really sure what's the state of your app or whatever you're building.
So engagements around this and getting awareness and enthusiasm around like this application security concerns and like they are as important as your tests and all of those cross cutting concerns are an important kind of building block in terms of the communication that we need to do between Snyk, between security companies that are dev first today, you know, understanding that developers are, you know, those that are empowered to fix issues, you know, security personnel are, you know, great and they're needed, their expertise. But in the end, you know, at the end of the day - developers need to fix stuff.
I think that's one of them. And I think the other one would be kind of super receptive to the fact that, you know, what are we not doing right? What can we do better? What are we missing? What are the gaps that we have, you know, with, like, you know, you mentioned Snyk specifically, right? So, what are the gaps that Snyk has in terms of, like, how do we communicate better with a dev community?
You know, the first place, probably where your users meet you, is in your documentation page, right? They want to start implementing and using your tool. And how much time and effort, and thought do you invest in keeping that friendly, and in order, and up to date?
It's a good question because I don't know, if specifically, for Snyk users are landing on the docs pages first. I think it's probably one of the blogs, or sometimes they’re getting sorted blogs that we have. But even when you talk about documentation, and like, that's probably a whole paradigm of itself these days. There's like the product related docs, and then there's like the API related docs or like, even like different things.
I think what we're doing is definitely keeping that up to date, with products and calling out. Like, if we see people are like complaining, or they're missing - like the same complaints all the time. Like, you know, we want to push this into, like an FAQ or something like that on the docs like to get people aware of this issue very easily without having to scrape for it or go through it themselves. So, there's definitely, I think, the awareness of like hitting them in this milestone of, like time to get started kind of like metric really fast.
Okay, great. Well, unfortunately, that's all the time we have today, Liran.
Thank you for having me.
Thank you very much for coming on today.
Thank you everyone for tuning in and I hope you'll join us for our next episode. To find additional episodes and full transcripts, or if you'd like to be a guest on our show, find us on our community page at Swimm with a double m dot io. Bye for now.