Polar

Ben Rometsch sits down with Birk Jernström, who shares the genesis story of Polar, a creator platform for developers. He explains how he established his company using his experiences and expertise gained from Tictail and Shopify. Birk discusses how he changes the status quo for open-source developers in terms of working on their passions full-time and independently. He also talks about the power of changing your perspectives and how he handles the needs of every single person down the dependency tree.

---

I’m super interested in having Birk with me from Polar. As usual, I'm in London. Birk is in Stockholm. Welcome, Birk.

Thank you so much, Ben. I’m excited to be here.

Shopify Experience

Before we get started talking about open source, I do want to dig into your experience with Shopify. I've not met anyone who works at Shopify and I'm super interested in hearing a tiny little bit about an absolute Goliath business and a huge open-source contributor as well.

The backstory there real quick is I started this company together with a few friends back in 2011 called Tiktal. That was an e-commerce platform that became a marketplace as well. Tiktal was acquired by Shopify back in 2018. That was my entry point into Shopify and the reason why Tiktal was acquired was we built an e-commerce platform very similar to Shopify, but we've focused on expanding that into a marketplace.

When we were acquired, we got that mandate for the Tiktal team to look at commerce from the lens of the consumer side and what would it look like if we built a consumer side of Shopify? Their mission is to make commerce better for everyone. At that time, they felt that was the right time to expand their lens from merchants and also cover the other side of the consumers.

As a product person, that's probably you're a kid in Willy Wonka. You get to join Shopify, which is the leading e-commerce platform in the world. You have that exciting mission of building the consumer side and you can start from a blank canvas. Take all your experiences from Tiktal and apply them here at Shopify.

Long story short, what we built there is what is now the Shop app and the Shop Pay experience. That was something that we built. We discovered other teams within Shopify that were fantastic and were working already on that consumer side, the innings and beginnings of Shoppay, as well as Arrive, which was what the app was called before it became Shop and expanded.

We grew that team. The three years that I worked there were a fantastic time. What I would say about Shopify is that it’s amazing. I hope this is true for most founder-led companies out there, regardless of size. Even though we were several thousands and thousands of people across the entire world, it felt like you were still working at a startup in a lot of senses. That was amazing. I guess that was my fear going into it, “Am I going to die by these processes?”

That's high praise indeed. As a customer, it's amazing how tuned in I've become to try not to use Amazon. A lot of the time, prices aren't that good and you're worried about fake products. How tuned in I am that if I land on a site, I can see, or as soon as the Shopify checkout experiences, I'm going to buy this. The disparity of friction between homegrown e-commerce sites and non-Shopify is amazing.

I am continuously impressed with their products and how they've managed to close the gap on Amazon so much. Amazon is doing that, but it's all through one label in certain circumstances. One of the things I noticed with Amazon is a lot of people don't know how to look for the Fulfilled by Amazon thing. If that's not the case, the experience can be a dial. I've got a huge amount of respect for that business. Did you see the Christmas thing they did with the number of requests they were serving per se?

Yes, Black Friday, Cyber Monday, and the Globe. They did that long before even Tiktal joined Shopify. When we joined, Tiktal, it was awesome to see the scale that we grew into as well in terms of commerce, but Shopify is a different scale entirely. I remember 2018 looking at that Globe and being mind-blown. Every single year, you're almost doubling that in volume. Not just in volume but also they rented out the Globe in Las Vegas, which was taking it to a whole different level. I don't know how they're going to maybe project it on the moon or something.

Creating Polar

In terms of your life and work from Shopify, do you want to tell us a little bit about how you came to start working on Polar?

I quit Shopify back at the end of 2022. I was about to become a dad for the first time. I had worked on Tiktal and Shopify and made a decade's worth of work within e-commerce. I loved my time at Shopify and that company and what we were building, but I started to feel that itch again of starting something from the ground up.

I was becoming a dad. I felt it was good timing for me to resign, step back, get into the role of being a dad, and figure out what I wanted to do next, which was both a privilege and an awesome time to be in. I was rolling the stroller, thinking a lot about what I wanted to do next, building a lot of side projects like playing around with 3JS, which was an awesome unreal engine, maybe I was going to develop a game, just getting back into developer mode again and creating, which was awesome.

One day I was building this service and I wanted to integrate or build an OAuth provider as part of that. This was something that I'd done back at Tiktal in Python back in 2012. As a developer, what do you typically do when you stumble into a problem or something you need to build, you think, is there an open source solution for this that can accelerate my innovation, and how I can build this?

‍

Back then no open source solution existed for building an OAuth provider in Python. We had to roll our own. It took me about three weeks to develop, but now for a side project, there's no way I'm going to spend three weeks rolling my own OAuth provider. The first thing I do is go get up and I think ten years later, there might be an open source solution for this.

Sure enough, I found this library called Authlib. An hour later, I had solved that same problem that took me three weeks, ten years prior. It feels cheesy but every time I say this story, I get goosebumps. That sounds like a cheesy thing to say, but it's true. There are these moments when you stumble upon a new open-source library or no tool that you recognize the value that it brings because you built something similar in the past. You're falling back in love again with open source, like hard.

That happened to me and I'm falling in love with this library and then my eyes go to the right-hand corner and I see GitHub sponsors. I see that this amazing piece of library is getting $5 or $10 a month or something like that. I don't remember exactly what it was at the time. This disconnect right between the value creation versus the value received is so vast. That stark contrast wasn't news to me. I've always known that's been a problem within the ecosystem.

I think it was this perfect Venn diagram of timing for me. My background with Tiktal is how can you equip anyone to start their online store and create their own business. With my love for open source as a developer, everything fell into place for me to get super excited about the idea. What if you could change the status quo and build something that allows open source developers and developers to work on their passions full-time, independently, and even create independent businesses around it? That is essentially the backstory to Polar and why I went down the rabbit hole of how we can fix this super hard problem.

That's audacious. Did you feel like you were standing at the very bottom of a very tall mountain?

I recognize when I apply logic to the problem, it's a very hard problem. Can this even be solved? It's super hard to solve, but I think one thing about entrepreneurship in general is that you always have to be a little bit naive. That passion and excitement need to trump reality, otherwise, you're never going to do it.

‍

In entrepreneurship, you have to be a little bit naïve. Passion and excitement need to trump reality. Otherwise, you can never make it.

‍

Was it Paul Graham who talked about schlep blindness? There's another one as well, which is a quote that I saw that was exactly how I felt about Flagsmith. I don't know if you've maybe seen it. It’s like, “We don't do this because it's easy, but because we thought it would be easy.” I don't think that applies maybe to Polar because I think anyone with experience in open source and business and software engineering would see that as a hard problem to solve.

Changing Perspectives

The other thing that strikes me is trying to think critically maybe the solution has nothing to do with technology. Maybe the solution has to do with changing perceptions of things. I talked about this a couple of times before on the show, the nerd in me, whenever I hire a car when I'm on holiday, I always scroll through and find where they legally have to say thank you and whatever.

Some manufacturers are better at it than others, but maybe it's a social thing or maybe it's got nothing to do with technology or maybe it's got everything to do with cryptocurrency. There's such a wide gulf of potential solutions. You've got no idea whether any of them is going to work or whether you should be aiming down here or whether you should be aiming over towards let's start a new cryptocurrency, which probably wouldn't be my approach. How did you even start trying to think subjectively about the problem?

I think you're right in terms of changing the perception of it. There's one core hypothesis that I had as I was going into this rabbit hole and thinking about how you would change the landscape and how you could drive more funding within open source. It goes back to a story when I was young, my mom was working at this company and they were supposed to sell businesses to sponsor this charity event.

I was helping her out and I called these companies and I asked, “Do you want to sponsor this event?” I was able to reach the CMOs of some of the largest companies in Sweden. I still remember to this day, how I was able to get them on the phone but when I spoke to them, you could hear how I was dragging money out of them. They were not excited but they couldn't say no. They had this feeling of guilt.

In many ways, that's the narrative and the problem with open-source funding today. The reality is that a lot of value is being produced. With donations and sponsorship, having been the status quo, that model is essentially that you go to these companies and you say, “Look, you're building your business around these open source libraries and driving a lot of revenue, but these libraries aren't getting anything. You need to sponsor and give back.”

I reached out to hundreds of companies and tried to figure out a way how you can scale sponsorship. What became clear in those conversations is that I felt that feeling again in those phone calls where I spoke to companies saying, “We should and we will,” but you could hear that I was pulling that out of them. It wasn't something that they were actively looking for or would want to invest a lot in.

My hypothesis is to look at GitHub and look at the successful people. I think that's the best approach. There are Open Source maintainers out there getting substantial funding that is doing quite well. Rather than looking at the big problem that everyone is impacted by, “What are the ones that are successful doing that no one else is doing and how do you then replicate that?”

‍

Rather than looking at the big problem that impacts everyone, focus on the successes no one else is doing and learn how to replicate them.

‍

What became clear is that they're leveraging GitHub sponsors, whether it's Patreon or what have you, to upsell value-added services on top of their open-source library. A great example is Squidfunk from MKDocs Materials. I think he's getting $16,000 monthly, running his own business around this. It's on the premise that you need to sponsor it if you're using it commercially, and then you get access to some premium features before they're made open-source. You get priority support and all those things. It’s like the Red Hat model, but smaller scale.

Just to back up, I'm curious to know when you said you looked at the folks who were doing it successfully or doing it well, who are they? I know GitHub has a platform but in terms of other platforms or models or ways that are successful.

That was the problem, I think no platform was successful that actually democratized that model for every open-source developer out there. That became my theory. I think donations and sponsorship are great. Don't get me wrong. I sponsor a lot of open source myself. Do that but I think we've tried that model for decades now and it hasn't solved the problem. Let's try something else.

When I was looking at these open source developers that were successful on GitHub sponsors, the store was always the same. They were selling additional services. Premium content and updates, premium support, Discord invites, all these different things. The strategy behind Polar is why don't we build a platform that is on top of GitHub so that we're coding on GitHub?

That's where we host our code and collaborate on the code side of things. What's lacking is a platform that focuses on those subscriptions and makes sure that you can experiment with these different types of models of value-added services, even as an individual developer. That's the way you can then sell additional value both to end consumers, as well as businesses.

Development Stage

You had an idea or you had a concept and I guess you had some data in terms of open source folk that you've spoken to and companies that should have legitimately been paying well for some of this stuff. What happened next?

First, I thought about developing this individually like an indie dev, open source it from the beginning. That's always been a key thing. I started developing the first version of Polar. The first feature that I got a lot of businesses to say they got excited about was the idea of how can you fund specific efforts within open-source libraries that you depend on.

That was what Polar launched initially, which was this concept around every open source maintainer being able to add this beautifully embedded badge across their GitHub issues for their community to pull funding towards it, for businesses to pull funding towards it, and to be able to reward your contributors that help solve or build those features.

I started developing that as a proof of concept on my own, but I started to notice that there was a lot of stuff happening in this ecosystem, and I think that's fantastic, a lot of different attempts. I realized one day that, “Sure, I could build this one feature on my own, but to build that platform, which is a suite of different features and models that maintainers can try and developers can try, it's going to require more than me.”

It's going to take time. It's going to require marketing. It's going to require capital. This was before New Year's 2023, I decided I was going to raise capital behind this so that I could build a team and go at this head-on. We raised the pre-seed round and then I started building the team. This is early 2023 and then we launched the first version of Polar end of May 2023, which was around the issue of funding.

We iterated on that product throughout the year and then towards the end of last year, that's when we started expanding the product into what it is today, which is more of a Patreon for developers. Truly a platform where you can write posts and updates, have newsletters for your audience, and have paid subscribers for that and paid content.

Now we're shipping things like premium Discord invites, what we call ads, which it's crazy to me that maintainers today, one of the most upsell things is if you're a business, you can sponsor and get your logotype on my Readme, on the docs, and my site. That is entirely manual. You subscribe to that and then you have to email back and forth logotypes.

It's the 1990s all over again. We're also shipping that, which means you can upsell the benefits and say, “I need a logotype of these dimensions and you can have your name, you can have a link as well.” For those consumers to easily get that benefit and be able to upload their logotype seamlessly for that to automatically then be synced to your pull requests and your sites and docs and so forth. That's where we're at today.

Subsection Of Shape Of Projects

When you were designing the platform, were you targeting a specific shape of open source projects or because you've got a small library that one person looks after, and then you've got all the way up? I was looking at the Home Assistant code base today because there's a thing on it that I want, a little UXtweak. It was interesting. They've got a 16,000-person Discord community. The feature hadn't been built.

I was starting to look at the front-end code and I'm not a React engineer by a long stretch, but the code's amazing, It's super high grade. Impressive, so good that I could all aspire to the future. Those two projects are massively different, aren't they? You've got everything in between and then you've got people who are religious about it being open, free us in freedom. Did you try and carve off a subsection of the shape of projects to start with?

Absolutely. We continue to do that in many ways. Initially, with our first launch of issue funding, we were focusing more on larger well-known maintainers. For issue funding to scale and for that to drive value to those maintainers, you need a lot of dependence and a lot of traffic for your library for people to pull funding towards it.

We hit a sweet spot amongst that audience. Today, Polar is home to maintainers that together represent one and a half million GitHub stars. That's a big number. GitHub stars are quite scarce to come by, even though you can buy them these days it seems. Anyways, they surely haven't. First, we got popular amongst those larger maintainers.

The goal with Polar long-term is to cater to everyone and also help newcomers and starters to grow their projects and become those next big open source maintainers that we all know about. That's the position we're taking more and more with Polar these days. We're still leveraging our network and the community that we built to get these household names on board the platform.

More and more so as well, reaching out to people that I identify as diamonds in the rough. In the sense that you can tell that these people are on the trajectory and have the capabilities of being someone successful in the open source ecosystem? How can we help elevate those and put them on a fast-track trajectory?

A lot of that comes down to posts and newsletters where if you look at open source and the well-known maintainers out there, a lot of them are great at writing code obviously, but the very successful ones are also great storytellers around what they're building and the vision they have and bringing people along on that quest.

That's something that's not recognized enough in the open-source ecosystem and what we hope to help with as well. Equip maintainers with the capabilities of easily building their audience and owning that audience, keeping them up to speed, bringing them along, and getting more contributors along the path. That's how you eventually can grow a successful open-source project.

‍

Dependency Tree

I would imagine that there'd be a fair amount of apathy or cynicism from maintainers. Especially, I'm going to mention, the XKCD dependency, which is number 2347. This comes up on one in four of our podcast recordings, but I've felt that's fairly and completely understandable. This is not a criticism at all. Like a huge dollop of I don't know what the word is, there's probably a good German word for it and that I don't know, but cynicism or patheticness. “No one ever thanks us anyway, we've been doing this for years. It's never going to work.”

It seems to me that the folks who can tell a story around their projects are probably not a million miles away from being able to generate revenue from the project anyway. Whereas I feel like you've probably got all these people who are building these sub, sub, sub dependent, something that's three levels down in the dependency tree. It feels to me that they're the ones that are the most deserving, where there's no interface. There's no product. It's a second or third-tier dependency thing. How do you solve that?

To that answer that specific question first. You're right. You mentioned that library you found earlier, React, for instance. I think React is one of the larger open-source projects out there. If you're working on a project that is more a framework of how we're developing web apps, obviously that's a framework that's going to be top of mind for a lot of developers. When they think I'm using open source, React might be the first thing that comes to mind.

Then there are 50 layers underneath that where there's this guy in Nebraska from the XKCD sketch that's unknown and developing some part of the infrastructure. What we've found with Polar and my hypothesis as well is that I think that's fine, to begin with as long as you make sure that there is a funnel where that is passed onwards across that stack. If people want to drive a lot of capital to the first open source project that comes to their mind and subscribe to that, let's start there and drive more capital towards it.

What we found with those maintainers is that they in turn understand that they have their own set of dependencies. Now they're subscribing and they're taking the revenue that they're getting or the issue funding that they're getting and then passing that on and investing that accordingly across their transient dependencies as well. I think we have a lot of ideas around that as we reach scale on how we can automate that even further to make sure that this trickles down.

I'm getting Thatcher-Reagan ‘80s capitalist politics going on here. That's the other thing as well, which is that it's not that because engineers instinctively know that they owe. It's interesting hearing you talk about that because Flagsmiths have large customers and some of them pay us quite a decent amount of money.

If they say, “We need you to develop blah,” we'll do that. Most of the time, that will be open source or almost always if you squint hard enough it's similar. They're paying us for other stuff as well. I worry that it's much easier for us to leverage that than it is for the guy or woman in Nebraska to do that because they've got no leverage. Especially those sub, sub, sub dependencies need to be probably even LGPL licenses because otherwise, large projects wouldn't be able to use them.

Was that immediately apparent to you straight off the bat in terms of this idea of building tooling around trickle because it feels you could do it? That's one part of the problem that you could not solve, but technology could help in terms of traversing those dependency trees and figuring out who's owed what.

Going back again to a lot of stuff happening in the space, which I'm excited about, is you have StackAid, you have Thanks.dev as examples. I think they're fantastic. That's exactly their bread and butter, where you can upload your package JSON or your requirements.txt, whatever it is. Set your funding amount and that gets automatically dispersed according to your dependencies.

If those guys are listening here, I think eventually, and maybe six months down the road, those types of partnerships are partnerships that I'm interested in as well. We have some ideas also in terms of our subscriptions because typically we're building on FastAPI as an example. FastAPI depends on its Uvicorn starlet identic. There's this huge stack of open-source fantastic libraries in there. I'm very well aware of that.

I want to set up a way where such a project could set up their subscriptions and for that automatically highlight, “These are the projects we're building on top of and the funding that you're giving through the subscription also goes to that stack.” That's one idea and I think we can then partner with a Thanks.dev to take that even a step further and go down the entire dependency chain.

One of the learnings for me going back to Tiktal and entrepreneurship in general or any problem right now is that we tend to talk about problems as singular. What you recognize when you start a startup or try to solve that problem is that there are a million problems underneath that one umbrella problem that you're trying to solve.

That's the case for us. We won't solve all of them from day one. Our first aim right now, and a core fundamental belief of ours is if we can equip developers with ways of offering these value-add benefits that a lot of them are upselling today already, what we've seen chatting with hundreds of companies, a lot of them are a lot more excited to open up bigger portions of their wallet and invest more significantly. We can then start driving more capital to individual developers.

‍

I love to then get to that point of, “Now we're starting to scale this. We're seeing that individual developers are getting a lot of money here and can live off of it.” Now, how do we help make sure that that is being passed on?” We'll do that from the onset, but it's a continuous thing we need to optimize for as well.

I'm curious to know what's the reaction. You must have a huge variety of reactions from people going all the way from, “Brilliant, I want to get that started,” all the way to, “Go away.” Some people can get quite religious about this.

Working in this space and having that belief that you can solve the problem or create a pathway at least towards independent entrepreneurship within open source. You need to be comfortable being called an idiot more than once. I'm sure people who are reading this episode are thinking I've lost it or something.

‍

When working in the open-source space, you need to be comfortable being called an idiot more than once.

‍

That's fine. There are a lot of people within open source as well that are very religious that open source means free and that it's more political that capital in itself is the problem. That's fine. We won't cater to everyone and for people of that segment, this is never a problem to begin with because they're not looking to live off of their open-source passion and work on that full-time and drive revenue towards it.

That's a natural filter where we do have a lot of excitement and obviously, that excitement is amongst developers wanting to pursue this full-time and even wanting to build independent small businesses around their open-source projects over time. That’s the segment that I feel is the future as well as the one that we're catering to the one that we're excited by and the one that we want to help support. We don't have to be for everyone.

Venture-Backed Companies

That's exactly right. Otherwise, it's an impossible task. My feeling on this, I'm old enough to remember life before almost any of that. It does feel especially in the last five years more of a pragmatic relaxation of what open source is. There's maybe even a generational thing as well a little bit. There used to be the GPL and basically, that was it. That was the first concept.

Now there's everything in between to business source etc. People are a little bit more okay with saying, “I'm going to do this to try and make a legitimate business,” rather than, “The bios on my computer have to be free as in a freedom thing.” If that's what you want to do, I'm not saying either of those approaches is right or wrong, but it feels like there is, especially with companies like GitLab and HashiCorp and maybe the second wave of public floating companies that feel like more people are saying, “It's okay to do that.”

I'm glad you brought it up because this is something that I've been thinking about quite a bit. It's an interesting moment in time for open source right now where there are a lot of debates and new licenses coming out and a lot of experimentation. If you go on Hacker News when new licenses are launched and so forth, there's a lot of skepticism towards that initially.

My take on that is if we go back to the origins, I think open source has existed since the dawn of computers. That's where it started. You had this time when you had Linux versus Microsoft that still echoes through the dialogues and discussions today. When something starts, it's natural that you have two extremely polar opposite viewpoints.

You have the extreme capitalistic one and the free Linux mindset. The nuances of the open-source discussion today are a reflection of the fact that open-source adoption has skyrocketed and open-source is through everything these days. When more people are involved in something, obviously there's going to be a lot more nuance in terms of the perspective. That's what we're seeing in terms of all the different ways of slicing and dicing what the definition of open source is today.

Separately, you're exactly right. You had Red Hat, which was one of the pioneers of this type of model within open source. You have GitLab and a lot of other ones that are successful and have IPO'd, and then you look at VC funding for commercial open-source startups today, which has skyrocketed and ballooned.

I'm incredibly excited about that and that tells the story. You had some of these outliers and initial pioneers that did what someone thought was impossible, and proved that model. Now you have this growing market of commercial open source forming and getting a lot of venture backing. Whenever you have that in a market, the long tail is bound to follow.

‍

Thanks to some open-source outliers and pioneers, we now have a growing market of commercial open-source forming and getting a lot of venture backing. The long tail is bound to follow.

‍

At the core of that is essentially what Polar is. It's like you have these commercially open-source venture-backed companies. How do you replicate that and allow that to be accessible for individual developers and everyone to pursue independently because not everyone is going to be eligible for easy backing? That is the platform that Polar is building.

In many ways, that's probably an inspiration from taking a Shopify that has this sort of mantra of arming the rebels. I think that's the same thing, It's about how you initially start with equipping everyone with those superpowers of building the next big companies that IPO. That has come out of Shopify these days and hopefully that same journey we can replicate, but within open source.

It's super interesting. I do agree with you. It's like rich anarchists. I wouldn't put them down as anarchists but like David Kramer for centuries. A couple of years ago now, they donated a ton of money to supporting open-source projects. I think it's interesting that those second-wave companies have now got some of them extremely, massive companies. Very successful and very rich founders.

I'm going to put 1% of my profit and I'm going to pay that back or whatever. Thinking about it, it's interesting you bring up the Microsoft-Linux thing. It's hard to overstate for those people who are reading who weren't old enough to be around for that time, how bad that was. Not bad, but how intense it was. It was like a real Death Star and the first is the R2D2. It was crazy how polarized it was.

I'm going to paraphrase a quote, but I think Microsoft calls Linux and open-source an anti-American. It went beyond software. It was hardcore politics.

Sustainable Business

Like the Slashdot days. I remember first seeing Visual J++ and Java wasn't that old. They came along and started butchering that language and specification. It's strange how much the world's changed when you think about it through that lens. in terms of Polar, how have you squared the circle of that as a sustainable business? How do you go about paying the engineers that are working on that platform?

Our model is that we have no fixed monthly costs for you as a maintainer or as a developer to use Polar. Instead, we take a commission, which is 5% of the subscription and funding that you get through issue funding and so forth. Besides the 5%, payment fees from Stripe apply as well. We’re very intentional to make sure that our pricing is aligned with the success of our audience and the developers on the platform.

When we launched, we set 10% as our initial commission. I'm very happy that we've since then lowered that to 5%. We need to strike the right balance where we can pay for the operational costs and sustain this business long-term. We are in a fortunate position to have Runway for a few years now, which is fantastic. Ultimately, our long-term vision is to empower as many developers out there as possible to earn an income on this, to hopefully work on it full time, and even build smaller businesses on it. I'm excited to take the least amount that we can to scale this to the biggest market possible and still make sure that we can pay for our own lighting and our operations to build that platform.

That sounds more than reasonable. It's funny how the 30% app store take has price-anchored stuff so crazily. I remember telling my brother, that he works in finance and he didn't know that it was 30% we were in the pub and he spat his beer out of the pub, he couldn't believe how much they were taking, but that sounded eminently reasonable. Then in terms of the business structure itself, is it a for-profit business, or how did you go about it? Did you think about doing something different to that?

From my perspective, going back to the discussion around for profit and profit, perhaps historically being a frowned upon term even within the landscape. I'm proud that Polar is for profit because we're for profit and our pricing model is that we can only make a profit if we drive significant profits to end developers. That's the shift we're pushing towards. What we hope to equip developers with right now is that it's not everything you can still obviously build your projects open source.

It's a lot of ancillary things that go into running successful open source. You do end up doing support. You do it for free. Like you do end up prioritizing issues from bigger companies. You do it for free. Chatting with these companies and individuals, a lot of those extra services, people are happy to pay for that. That is what we're pursuing and hopefully making more people profitable within open source and for Polar to be profitable as well.

‍

Plans For 2024

What's the next plan for 2024?

Right now, we've launched the second version of our platform or the expansion into a platform a few weeks ago. We’re excited about that. We have some developers who signed up and started posting and using our subscription model. I overheard a quote that after two weeks of using Polar, they have four times the amount of income than they do from GitHub sponsors after two years.

That's super exciting. It's still early and smaller scale, but it's validating that model. A big focus of ours now is focusing one stack at a time to focus on driving well-known maintainers within a stack and then helping smaller projects that haven't been discovered yet within that stack to become discovered through Polar.

Build those network effects one stack at a time and then create a lot of marketing activities around celebrating these open source stacks and have some ideas there on how we can drive significant commercial investments behind that and more awareness and celebration one stack at a time. Beyond that on the product side, it's listening to the maintainers and their feedback.

Now that we launched, we have a long list of requests for different benefits that we can automate to offer in our subscription model. That's a huge thing of ours to continue to iterate on that and improve how you can reach a wider audience for maintainers as well through posts and building that audience that you can own and engage with that's not locked behind GitHub stars.

Closing Words

That's great to hear. Thank you so much for not shying away from thinking about that problem and running away screaming like I think most people would have done. It's a great story to hear and in terms of where's the best place for people to find you? Plug some URLs, whatever you want.

First, thank you so much for having me. Thank you for those kind words. It's an exciting journey and we welcome every open source developer and developer out there. You can find us on Polar.sh, on Twitter we're Polar_Sh, and on GitHub, Polar is built entirely open source itself, PolarSource/Polar is the name of our repo. I guess go to Polar.sh and you'll have all of the relevant links in there.

Thanks again. This is one of those episodes where I'm going to put a reminder in for three years or whatever and see where you're at because some projects have fairly clear paths and trajectories. This one is super fascinating. Thanks again, Birk. Good luck for the year.

Thank you, Ben, and likewise. I’m looking forward to having that conversation three years from now.

Thank you.

‍

Important Links

• Birk Jernström - LinkedIn
• Polar.Sh - Website
• Polar_Sh - Twitter
• PolarSource/Polar - GitHub

‍

‍