Earning Trust With Tom Hacohen ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fimg.transistor.fm%2FjWinFBOdCsk_uouTFPIaKFoiPINazJ2uKEubLYthLNg%2Frs%3Afill%3A0%3A0%3A1%2Fw%3A1400%2Fh%3A1400%2Fq%3A60%2Fmb%3A500000%2FaHR0cHM6Ly9pbWct%2FdXBsb2FkLXByb2R1%2FY3Rpb24udHJhbnNp%2Fc3Rvci5mbS9zaG93%2FLzEwNTI5LzE2NTY1%2FMTIwMDAtYXJ0d29y%2Fay5qcGc.jpg&w=512&h=512) ## Metadata - Author: [[The Business of Open Source]] - Full Title: Earning Trust With Tom Hacohen - Category: #podcasts - URL: https://share.snipd.com/episode/27d27e19-7897-4a7d-8979-6b585f054a06 ## Document Notes ## Highlights - **From Linux Hacker To Open Source Founder** - Tom Hacohen describes his longtime open source journey from hacking Linux phones to working at Samsung and building EtarSync. - Those experiences shaped his default choice to open source Svix and influenced product and business trade-offs. Transcript: Tom Hacohen Okay, let's start from the beginning. Okay, this is actually, I'm going to go way back, but I started coding when I was nine. I found that whole idea just like fascinating. And then I don't remember how, but I got introduced into Linux. And I just installed Linux. Probably was Slackware or maybe Mandriva before it was renamed to Mandriva. I don't know, something old anyway. And I was just fascinated by everything about it. And that kind of like got me introduced to this world of open source software. I was just like, oh my God, this amazing thing was built all by volunteers or mostly by volunteers, I guess, at that point, compared to like Microsoft, which was I don't know how big of A company back then. But like, I was, you know, like, I was being sued as a monopoly, like across the EU and the US and all of that. So like, I guess, large enough. And I was just fascinated by it. And I started using it day to day and then kind of exposed to more things along the way and then I remember you know I was in like part one like one open source community and I heard of this Thing called OpenMoco I don't know if you remember that one I don't yeah I mean it never really really took off but it was like an open source software open source hardware mobile phone It came out just before the iPhone and just before Android as well. So it was this amazing thing, like a fully touchscreen phone that runs Linux and you can hack on. So obviously I had to get one. You couldn't get them where I was living at the time. So I asked my uncle from America to get me one. He bought it, brought it back to me, and I just started hacking on it like nonstop. It was just like, so I, I became one of the maintainers of the, the main distribution for open MoCo, um, like called SHR, whatever, but I was like writing a lot of software really all across The stack. I even like wrote a patch for the kernel that wasn't accepted in the end, but like a version of it was, and just like, just really touch every part of the stack. And we're just, again, just fascinated by how much i can build um and i think like some of the things that we did back then also like ended up being adopted by android and i also maybe just Reinvented in a different way um but that kind of like led me to i mean because of that i got a job offer at samsung um they were creating their own mobile os that's linux based i honestly Don't it changed name so many times i think it was called samsung linux platform when i joined but then they merged with memo and migo and then they kind of like split again and now and then Towards the end it was tizen and but yeah i was like one of the main developers for that and doing like all of the ui stack um i started by doing you know like support for like right to left Languages and just kind of like then evolved to everything so that's kind of like my less commercial aspect of open source but then you know at some point you know i was always like very Interested in security and privacy and there's a project that i always wanted to build which is like enter an encrypted sync for all of your data. So essentially sync your data in a way that not even the server can see it. Like only the clients can have access secured by strong cryptography. So built that. I want to say it was like a business decision to make it open source. But really it was just like I'm an open source guy through and through. So I just like defaulted to that. And that kind of like took off on its own and became this like, again, B2C product that is fully open source and people pay just for the hosting or they hosted themselves. I think most people host themselves, but we still have like a large number of people paying for the host service. So that's kind of like Ettersync. And then like fast forward to today, I also created Svix. So Svix is my current company. We're backed by Andreessen Horowitz, Y Combinator, and a variety of like other great investors. ([Time 0:00:31](https://share.snipd.com/snip/54bd6c18-f05d-46aa-942b-b83dc9215001)) - **Open Source As Default, Not Banner** - Svix is open core because Tom defaults to open source and because developers prefer open source. - The company doesn't foreground open source as marketing; it's how they build, not who they sell as. Transcript: Tom Hacohen So as I said, I don't think it was like a, I mean, it's a variety of things. One, I think this is just how I, how I built things always, always built things that way. And I mean, I'll add the caveat that, you know, I have investors, team, you know, customers, all of that, like have a lot of responsibility nowadays, I can just do willy nilly what I want, Because I want open source. But I think it also really made sense from a business perspective um and why is that i think as a developer i default to using like open source products um like i prefer open source products I'm okay with mostly okay with fsl like for a license and all of that and but otherwise i default to open source and i think the distinction that i made when you reached out as well is that Like a lot of companies what they do is that they use that as their marketing banner for them. Like we are the open source X. This is all we do. And we're going to track GitHub stars as a metric. And this is all we optimize for. And like you see a lot of companies do that. We, I mean, we care. I don't want to say we don't care. It's like vanity metrics are always fun. But we don't, it's not something we optimize for. It's kind of like we open source just because it's what we do, but it's not who we are, if that makes sense. ([Time 0:05:03](https://share.snipd.com/snip/e32bbbe9-50da-4bad-bc17-8473acfad598)) - **Developer Influence Beats Buying Power** - Developers lack purchasing power but hold influence by choosing and pitching tools internally. - They prefer open source because it avoids sales interactions and provides an escape hatch via self-hosting. Transcript: Tom Hacohen Let me split that into two parts. So yes, it's true that developers don't have buying power, but they do have pitching power and they will not adopt. I mean, I don't know if it will not, but it's going to be harder for them. Okay. Let me actually take a step back. So like if they go and they search for a solution online, I think they're way more likely to choose the open source one than the closed source one even if only just because they don't want To talk to a salesperson um so they just wanted to go and try something and if they have a docker pool or something like that they can just use or even if they they see that there's an open Source part of the product and they can just go and sign up they always know they can default to the open source version and so i think that actually really helps um for developers and but You're right they this is the hardest thing or one of the hardest things about the there are two hard things about developer tools i think um one is that developers think that they can Build it themselves um and by the way they're right like the developers we're developers we built it so i assume that other developers can build it and the question is, do you want to waste Your time on it? And the other part is that they really, they're not used to buying software. So they usually don't have budgets. And even when they do have budgets, they don't even realize how to exercise them. And so, for example, to a salesperson paying 200k for like a SaaS solution sounds like peanuts, right? I mean, I'm going to increase sales by, you know, 50k per rep. That's like, that's a no brainer. For a developer, you know, paying more than 20 bucks a month sounds like a huge expense because they don't they're used to thinking about budget as a corporate they used to think about Budget themselves. ([Time 0:07:48](https://share.snipd.com/snip/e6c07aab-b0fa-4173-8d82-83ccb2f59c34)) - **Optimize Differently For OSS And Cloud** - Make different technical trade-offs for open source vs. cloud: prioritize ease of self-deployment for OSS, and availability/scale for cloud. - Choose simpler components (e.g., Postgres for OSS) and complex infra (e.g., ClickHouse) for the hosted product. Transcript: Tom Hacohen I mean, for example, we use ClickHouse in production in the cloud version, but we don't use it in the open source product because most people don't know how to run ClickHouse in production And just makes it way more complex for them. So we actually, that was an easy decision. We just like, we want to keep open source easy to run. Postgres is probably good enough for most setups. And so we just do that. And so I think that's one thing that drives the decision is really the different goals. In terms of what I assume you're asking, which is like where they conflict. I want to say we have a system, but it's really just like we sit down and make a decision. You know, like go-to team wants to make things only under the enterprise tier and nothing free and nothing open source. Developers want to make everything open source and free. And then we kind of just like decide something in the middle. Yeah. Emily O'Meara You have an arm wrestle on whoever wins? Tom Hacohen Yeah, exactly. The problem is the go-to people go to the gym a lot. So the engineers, always a disadvantage, unfortunately. Emily O'Meara So you said that the open source and the paid version have different goals. Can you tell me, dig into that a little bit more? What's the goal of the open source and and actually i'm not sure if you mean goals for the company or like the user has a different goal i mean i think more that everything is a trade-off Tom Hacohen And and for open source we made different trade-offs compared to to like cloud so i think maybe a trade trade-offs would have been a better way to put it and so one thing that i mentioned We don't care at all about how easy it is to deploy when it comes to the cloud. Like our cloud deployment is like very complex and has like, again, ClickHouse and Kafka and a lot of just like different tools. But for open source, we want to make it so you can just do Docker Composer up and have like a semi-production version and then like a few tweaks and you're ready to go. And like in a full production environment, no worries, because you already know how to run postgres in production you already know how to run Redis um so like going from there to production Is just extremely easy and again it's just not the case for cloud um so I think that would be the main thing but also you know like we do some crazy things in cloud to make sure that we have Absolutely like zero downtime, like not even like if we have a second of downtime, my phone is going to buzz like crazy and like people are going to complain and, you know, because we're Just core infrastructure for our customers. Well, with open source, it actually, when people run it on their own infrastructure, they can, they make their own trade-offs, they make their own high availability requirements And we can support them in doing that. But we definitely don't want to start, again, it goes back to complexity, which is like, hey, this is how you run a fully zero downtime service, which you don't care about. Because actually, your own service has one minute downtime once a day anyway. So why do you care about shaving that one last half a second? ([Time 0:10:29](https://share.snipd.com/snip/383f57e2-6c11-457e-b91a-659cd7b0a0b6)) - **Big Users Ghosting The Vendor** - Tom says large companies run Svix open source but rarely talk to the team, leaving limited user insight. - He finds it hard to learn about many self-hosted users because developers often avoid conversations with vendors. Transcript: Tom Hacohen Have very large companies using the open source product. And the unfortunate thing, I don't have a lot of information there because they, you know, as I said, developers don't like talking to salespeople. So I actually have no idea. We know that they use us because we've managed to like exchange it like an email every now and then when they have a question. But we just have no idea and i think in general though like most quote quote like corporate companies like i mean corporate companies of course but like corporate people or corporate Developers they would probably prefer going for the paid version rather than the open source just because it gives them this whole envelope of support of like, you know, we have page On call engineers to help. So I think like the open source, like who would benefit, it's like really the more budget constrained people. But even then, I think the cloud is such a good offer. Like we have a free tier. So, yeah. Emily O'Meara So you mentioned developers don't like to talk to salespeople, which is probably true. Who do they like to talk to? Like, how can we get the developers to talk? Tom Hacohen I mean, if you find out, please let me know. It's such a struggle. Because even, you know, ([Time 0:13:50](https://share.snipd.com/snip/9facc61e-2bf4-436e-8c2c-776ee9f39bb6)) - **Set Clear OSS Boundaries Early** - Treat open source as a resource-intensive distraction and set clear support boundaries to avoid constant unpaid engagement. - Decide early what stays free versus paid and be prepared for painful changes if you shift that line later. Transcript: Tom Hacohen Yeah. I mean, I think first of all, it's a distraction, you know, no matter how you carve it, having like essentially two products, even if it's mostly or like 99% the same code base, and you Still have, you know, different requests, different priorities for both of them. Like, I mean, for example, one of the things that is most frustrating about open source is that people can change it, which is a good thing, right? This is the part of the idea of open source. But the problem is that people change it and they don't tell you they change it. And then they complain about an issue. And then you're just trying to like hunt it down and it's just impossible. And then, you know, like few hours of developer times in, like you realize that actually they just like made a silly change that obviously changes the behavior. And for better, I mean, I spoke with like one open source founder, like a few years ago that he built, I mean, nevermind which company, like one of the most significant open source companies. And he said, we had a very strict rule. We don't do any support unless you pay us. And it's exactly because of this, like you just go into this tangent with people that don't necessarily know how to be supported if that makes sense and you just like waste a lot of time So i think that letting yourself get distracted there is like a huge risk and the other one that you alluded to which i think is like a risk with any freemium product but with open source There's no backsees right the moment you open source something that's kind of like it's it's out there with a free tier you can always change it later and and i mean grandfather people In but still change it for future people is that tension between what is what do you charge for and what is free and what is included and what is like requires a license and and it's a painful Change it's a really painful one first of all i mean you waste cycles internally to make the decisions but also if you make it a bit too too free or too liberal libre um like you're screwed Right no one is going to pay you and i think you know a good example of that was docker like docker extremely successful company changed the world uh i mean not coming some project maybe Changed the world and but then they had to make like those difficult changes to the docker desktop uh client in order to to monetize and i think now they're probably doing well. But for many years, it was very difficult for them because they didn't have a clear line of what's free and what isn't. ([Time 0:16:04](https://share.snipd.com/snip/d612fded-1d4e-4786-b61d-e87e67ca50d2)) - **Lead Decisions, Don't Vote Them** - Resolve internal OSS vs. GTM tensions by sharing context and making decisive leadership calls. - Avoid democratic paralysis; prioritize consistent decisions that balance product and sales incentives. Transcript: Tom Hacohen You just communicate context, just share a lot of context, and then make the decision yourself um i i don't think this is place for democracy and like i think someone has to be able to make Consistent decisions here or at least that's what we've been doing and but again taking everyone's thoughts into consideration understanding that like developers they just want Everything to be free because that's how they want to consume it and by the way again i am i'm that i have to fight myself as well like quite often and then the go-to people they just want To sell more they want to increase the ticket sizes they want to add more friction they want to get big a larger part of the pool into paid and so you have to understand that this is their Incentive this is what they optimize for and you just make the decision and like the line where you want to cut it. ([Time 0:18:42](https://share.snipd.com/snip/8f4efcc4-3862-4f0b-bbc5-6a0468d1aa5d)) - **Transparency As A Competitive Discipline** - Open source grants earned trust and an 'exit path' for customers that keeps vendors honest. - That transparent fallback helps close deals and aligns vendor behavior with customer needs. Transcript: Tom Hacohen Yeah. So I think first of all, it gives you like a lot of leeway with developers. They kind of like they trust you more. And by the way, this is like trust earned. It's not trust tricked into being trust. Because you do, you know, when they report a bug, we actually do listen. And when they have a patch, we actually do look at it. Unfortunately, this dynamic has gotten a bit murkier nowadays. Because I don't know if anyone else spoke about it. But a lot of people now at university, they've been told that in order to get a job, they need to contribute to open source. So you get a lot of low quality contributions that don't make any sense, especially with AI now. We've had a lot of AI contributions that just don't make any sense. Or a lot of just contributions that may be human, may be AI, but still don't make any sense. But I think putting that aside, i think that extra trust that you get from the community like really leads to better collaboration and and i think it's also and that's why we choose as Well as you know like open source vendor is that like knowing that you can always escape right i mean if this this this relationship turns sour you can always just like self-host it even If it's like extremely painful, even if you may have to develop some custom things that are enterprise version only and not available, you still know that there's an exit path. And I think it keeps both us honest and knows that our customers know that they can keep us honest as well. Again, I want to believe that we would always be honest regardless, but actually having that sword over our neck is useful, I think helpful for us as well. ([Time 0:20:13](https://share.snipd.com/snip/808ad782-ec95-43f7-9747-0235d4dc7dcf)) - **Be Ruthless And Transparent With PRs** - Lower community engagement when you lack capacity to mentor contributors and be explicit about participation expectations. - Offer to take over low-quality PRs while giving credit to keep velocity high. Transcript: Tom Hacohen Yeah. So we used to be extremely, and I guess maybe just like a function of being like early on and then like, you know, growing as a company. But in the beginning, we used to take everything extremely. And that's actually, by the way, was also before AI. So maybe that also changed. But like we used to think, take every contribution extremely seriously, walk with them, like nurture them, help them become like a better contributor. But then we realized that, you know, a part of that implicit contract that I've always had in open source, you know, like in Linux and Linux distributions, all of that, which is, hey, We help mentor you and you become part of the community. It's just not there with a lot of those contributors. So we actually, we took a step back and we've been saying no to people and we've been saying, I mean, no for features we always said, but like no, it's like, hey, we appreciate the time you've Taken. We can't accept this patch at the moment. I'm sorry. Oh, and then they asked you, what can i do better i was like hey i'm sorry we just we don't have the capacity to to mentor you at the moment so like we've just really taken a step back and lowered Our bar of participation because i mean a lot of times those prs you know i mean we have a team working on the product right so like i i want to believe that like most bugs are going to be fairly Shallow they They're not going to be like acid things. So a lot of them we can just fix ourselves much quicker, which we've done as well. We've offered people to take over the PR and just give them credit still, but just take over. So like, again, if to summarize all of it, it's just like take a step back, engage less and with people that don't seem like they engage because they want to be part of the community. And yeah. ([Time 0:22:20](https://share.snipd.com/snip/c404c994-0476-4236-a368-8f0be622a2fa)) - **Visibility Attracts Quantity, Not Quality** - Drive-by low-quality contributions often aim to boost resumes and logos, especially for well-funded, visible projects. - Lesser-known projects attract fewer but higher-quality contributors who care about the project itself. Transcript: Tom Hacohen So one heuristic I use, I don't know if it's a good one. If they've already, if they know the product in and out before, so like that means they already are using the product. They're just really frustrated by this one thing and they want to fix it. That, I think that is worth engaging with. If it's someone that just goes in and comes and makes a patch, it doesn't make any sense. And they ask you or ask you questions that don't make any sense for someone that even use a product for like a day or two days definitely not someone that went with a product to production I think that's very easy to just you know cut them loose and like let them go which by the way for my other project for like etysync um it which is way more esoteric and not backed by like a Name, like a company with like investors and all of that, like we don't actually have as many like low quality contributors because of that, I think. So I can even like see the difference between those two. Emily O'Meara Like, tell me more. Like, you think because it's a lesser known project or there's not, like, big money backing it, that you get less contributions, but the contributions are higher quality? Tom Hacohen So this is just me guessing. It's not backed by my PhD on open source contributions. But I think what's happening is that those people that do those low quality contributions just want to collect logos in order to get a job. So like, hey, I worked with this Silicon Valley startup and I made some significant contributions there. And I think and they're backed by Andreessen and YC and all of that. And I think like you can't really say the same about the other project, which is very successful in its own niche, but no one has ever heard of it outside of that niche of the privacy-focused People. And so I think that definitely helps. But I also wonder if the way they find Svix in the first place is by going to YC, searching for open source products, and then just going like drive by contributing there. So again, no research has been done to like make that, but like they surely discover somehow. And I assume it's through that kind of mechanism. ([Time 0:24:05](https://share.snipd.com/snip/8b240aa6-ba3e-46e7-8a2e-c2e90a9d145f)) - **Operate OSS With Business Discipline** - Run open source professionally when it's your business: formalize policies, billing, and support to avoid chaos. - Balance high-touch service for paid customers with limits on free- and low-tier support to stay sustainable. Transcript: Tom Hacohen So I think this time around, it's actually a business. I think I mentioned it like we have, I mean, again, that one was also a business in the sense he was making money and, you know, like we have, I don't know, accountants and all of that. So it's like incorporated. But here, this one, we actually have, you know, like staff and investors and all of that. So like, I think the responsibility of just being extremely deliberate about it um you know is significant i mean i'll give you one slightly tangential example but like in with the other One sometimes when people would have billing issues or like stuff like that or like they would have like annoying questions about billing i'm just like oh don't worry i come to you for Like the next few years just like leave me alone um i mean leave me alone in a nice way but like don't worry about it and i think here i don't think with Svix, I can just like willy-nilly comp Comp accounts without having like, at least some sort of, you know, like policy or some sort of structure around it. And so I think in that way, like it just, the level of professionalism, I guess, is different, if that makes sense. And that affects every part of the business. Emily O'Meara Do you feel like it's less fun? No. Tom Hacohen So I think it's more fun, at least in one aspect, I'll elaborate on that in a second. But no, I think what I'm driven by, I like building cool stuff. And I think here I get to build cool stuff. And the other one was like building cool stuff as well. But here I think the impact is way more significant. You know, I was on a United flight the other day and like there was an ad on my screen. And that was like an ad by a customer. Like there was like a big announcement that moved a lot of stocks, like in the public markets, like last week or two weeks ago. That was like one of our customers that caused it. Like that level of impact, I think it's just like a lot of fun. And I'm like definitely driven by it. Another area, but this is, again, a tangent. The other one was B2C. This one is B2B. And I am very big on support. I was a waiter when I was younger. I think service has always been extremely important to me. I was killing myself by providing B2B quality service to $2 a month customers or even free customers sometimes. That was very painful. Actually, I enjoy it. I can give the level of service that I want. But without, you know, without just drowning, I guess. ([Time 0:26:42](https://share.snipd.com/snip/d785abd0-7b08-4eb2-8590-a4848d14ddc6)) - **Customer Champion Who Bet Her Promotion** - Tom recounts an early customer champion who risked her reputation to push Svix into production and later got promoted. - That story shows how vendor reliability earns real career trust and long-term customer loyalty. Transcript: Tom Hacohen So I'll give you an example, almost an example to the opposite, but then I'm going to go to actually answer your question, which is we have one of our early customers, the champion, like Who was a senior engineer from that team. And she fought everyone. Like, actually, she saved the deal, to be honest. I would have lost it. Like, thanks to her, the deal went through. And she fought everyone to get the deal through. And then they're a very happy customer nowadays. And she got promoted mostly because of this according to her um but and by the way she and she fought for us because of that trust right she knew that we were there i like i'm not gonna i'm Gonna kill myself to like make sure that she looks good in front of everyone and everything works and she knew that so that's why she trusted us and if that trust was misplaced and we would Have failed her and have endless issues for her and the company, she wouldn't have not gotten that promoted. And probably she would have maybe been phased out or maybe trusted less, given less opportunities. ([Time 0:32:55](https://share.snipd.com/snip/4bf771a8-ee7e-40fc-9be9-5d265f182083))