Ep. #135, Maintainer Funding with Birk Jernström of Polar

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Birk with Polar. Birk, how are you doing?

Birk Jernstrom: Hey, I'm doing great. Glad to be here. Super excited to chat with you today.

Brian: Yeah, yeah. We actually connected sometime last year, had a couple of chats actually. Actually I got wind of something you were working on, which is Polar, and super happy to see that it's out, live, ready to go, people can use it today. Polar.sh. But first, did you want to give us an introduction of Birk? Tell us who you are and what you do.

Birk: Yeah, absolutely. My name is Birk, I'm Swedish, based out of Stockholm here. I'm a self taught developer, I'm the founder and CEO of Polar which we'll probably get into in a minute. Husband, father of two soon, I'm expecting a daughter around the corner.

Brian: Oh, congratulations.

Birk: Thank you very much. Yeah, started developing when I was really young, 10 years old. I accidentally right clicked View Page Source on my favorite website when I was 10 and since then I've been doing this thing for 25 years now, which has been amazing.

Brian: Wow, awesome. Yeah. You have a bit of a track record too, as well, because you had at least one startup that was acquired by Shopify previously as well. So can you talk a bit about your background and consultancy? But also that experience as well?

Birk: Yeah, of course. So since I started out at a very young age, I ran a consultancy agency throughout high school.

Brian: At the age of 10?

Birk: No, not at the age of 10. I did do some clients at the age of 12, I think that was the earliest. But I really got into the groove of things at 16, 17, working for a large newspaper in Sweden at the time. Then I met three buddies that became my cofounders of this company called Tiktel which was an eCommerce platform that was really successful at the time, and morphed into a marketplace as well.

Back in 2018 we were acquired by Shopify to essentially lead the mandate of what the consumer side of Shopify should look like, which became the Shop App experience and Shop Pay eventually as well. I was director of product there for about three years, which was a lot of fun building that out before I left and started Polar.

Brian: Yeah. Actually I've used the Shop Pay experience and it's a great experience.

Birk: Yeah, it's awesome.

Brian: Yeah. Having my email just know what to do and when and if someone's using Shopify behind the scenes, some random Instagram or content creator T-shirt thing that I'm purchasing, yeah, it's pretty seamless so great job there.

Birk: Thank you. The team should definitely take the credit and especially since I haven't been there for a few years now. But it's an amazing experience and amazing app.

Brian: Very cool. But speaking of amazing experience in apps, you're now working on Polar.Sh so I want to understand and get to know the story of Polar, and basically the purpose it serves for now for the open source community.

Birk: Yeah. So to take a step back, Polar and what Polar is is essentially trying to solve a Holy Grail issue of how do you improve funding within open source and how can open source maintainers get better funding behind their initiatives? To make a very long story short, I was developing this thing on the side and I needed to integrate an OAUTH provider. This was something I did back at Tiktel, 2012.

There was no open source library at the time so I developed it myself, it took about three weeks to do. Now I found this library called AuthLib and an hour later I had solved that same problem 10 years later, thanks to open source. This happens so many times, right? I get chills even talking about it.

You've fallen in love all over again with open source. But the next thing I saw is that they're getting almost nothing in sponsorship, so that's the problem we're trying to pursue and solve. Today how we're going about that is recognizing that one of the bigger problems is that as you become a successful open source maintainer, you start becoming more and more overwhelmed with all of these issues and demands and feedback coming in from across your community.

They're all treated the same today. With Polar, you have this ability now to essentially crowdsource funding across your audience for specific issues or features that are impactful for them and that they can pool capital across those communities to help fund those specific efforts, which helps the maintainers get more of a funded backlog, which is stack ranked based on impactful priorities.

For the audience, rather than just plus-one-ing or waiting across issues or forking them and trying to ineffectively path these things themselves, they can now proactively help fund enough of those features.

Brian: Yeah. Actually we were just having this conversation internally at Open Sauce because it's the classic decision of engineering team finds a solution out there, it kind of works for them but the question now is do they support upstream? As a company, support upstream or go build it themselves? I think there was a solution that was like six years was the last time it had committed a push to it.

I think we ended up making the decision of, "Okay. We're going to add it to our lib folder and solve the problem, move one," because there was apparently no community in this project that solved one specific problem for us. But a lot of times we see a lot of marked down libraries that could be doing a lot of frontend React stuff, there'll be a solved solution upstream and it works.

This actually happened to me a couple of jobs ago, found the markdown library, it worked but it didn't work for specifically tables. What we wanted was to repeat tables that worked just like GitHub. It's a solved problem today. But I ended up going upstream and not really getting to the point of fixing it but I ended up doing enough work that someone could take it over the finish line of getting GitHub flavored markdown tables working in a random Angular markdown.

Anyway, long story short, there was a problem, I had a half a solution, I threw my experience into the issue and the hope is that's enough to someone else can come along and pick it up or get enough attention that someone can essentially just get the maintainer to do it as well. But it sounds like with Polar now you can provide an incentive or an awareness campaign around things that need to be done?

Birk: Yeah, exactly. I think going back to the first case you mentioned, unfortunately there's a lot of projects that are abandoned. It's quite a common problem. In part that is because they're not getting proper funding to be able to do this full time or stay committed to it. So I think in your case, the ideal solution would hopefully be that the project is still very much alive and the maintainer was still running that project because they were the expert on the domain.

For you and your business, it's not that we're preventing you from creating a fork or patching things and pushing things upstream but often that's ineffective and you're want to spend focus on your own products and you have scarce resources.

So now instead you have the opportunity to say, "Hey, we would love to have this feature and if that aligns with you and your goals with this initiative, we're happy to help funding that initiative together with the rest of the community as well to help solve your problems as well as their problems with funding."

Brian: Yeah. Actually when did you officially launch? I know we were chatting off and on, so I don't remember what the actual date was. But how long has it been live and ready to go?

Birk: We launched our private alpha in mid May and then we opened up for public signups end of June. So we've been live now for a month.

Brian: Okay. And how's the response been so far for Polar?

Birk: It's been really amazing. There's several hundred maintainers using the platform today, having more than 3,000 repositories connected with several thousands of different issues with our Polar badge embedded. That's a very important part, which is maintainers can basically control and say, "These issues or these features, those are the ones that we'd love to get funding for or allow people to crowdsource funding for."

And because it's a GitHub app, it's deeply integrated and automatically embeds that in a seamless and beautiful way. The growth has been really, really awesome to see and what's more amazing to me is just on our Discord, seeing people that are joining in and the sentiment and excitement around the long term intent of Polar and what we're building towards.

I think on a personal note, the maintainer that I mentioned behind AuthLib actually joined Polar organically the other week and just DM'd saying, "Great work." That was a really special moment.

Brian: Yeah. That's pretty serendipitous too as well. You never know where the random interactions and contributions in open source are going to lead to. Personally, I've had the benefit of working with folks that I've interacted with in open source and having them leverage Open Sauce to get insights into their projects. But how rewarding is that, that the AuthLib person is now leveraging Polar and now you can provide a bit of value after you got some value from them and their library?

Birk: Yeah, it's really, really special. Also, Polar is open source as well and so even having people starting to contribute now, filing feature requests and issues. It's been really, really amazing.

Brian: Yeah. And you mentioned the GitHub app, so what's the interaction? I'm a maintainer, I just heard this podcast, and now I'm probably on your website already checking it out. What's the next step? What's the interaction for them?

Birk: Yeah. So you would log in using your GitHub account, so it's an OAuth integration. The next step is that you can connect your repositories and you have full control which repositories you want to connect. Once you do that we, in real time, show how we synchronize all of your issues and pull requests associated with those repositories.

The next thing you're presented with is the Polar dashboard where you can see all of your issues, sorted by most wanted which is a combination of upvotes, thumbs up and reactions on GitHub, as well as future pledges and funding towards those specific issues.

Then you can customize the badge as well as the context on how that badge is embedded across your issues, and you can decide if you want to badge all the issues or just one on one through the Polar dashboard, or even on GitHub just using the Polar label.

Brian: Very cool. Excellent. Yeah, I've got more thoughts and ideas on just that, the reactions things that we can talk about after recording because we have a project we're actually work in progress right now on so I'm not able to talk about it yet. But maybe the next episode we'll talk about it, and we'll talk about our amazing connection to Polar after. So if you haven't subscribed and you found this randomly on Twitter, please subscribe to the podcast, people. Yeah. So the one thing I wanted to touch on because you had this quote Substack For Open Source, can you explain your longer term vision for Polar itself?

Birk: Yeah. Of course. So today basically I think the problem within open source is that it's pretty binary, so it's either free open source where there is donations and sponsorship. But that's coffee money and not nearly enough to run these initiatives full time.

Or you have commercial open source where there's only a few players around, they're typically venture backed and only very, very few subsets of open source initiatives are eligible for that. So the long term vision for Polar is essentially how do you create a platform to build independent entrepreneurship within open source?

Our fundamental principle and belief here is that that is about enabling maintainers to seamlessly craft add on services and subscriptions on their existing initiatives today.

What Polar is today is essentially like prioritized issues or prioritized support, expanding that even further to premium educational content, newsletters and updates to their backers. As well as premium packages that you can install through specific registries. All these things are things that we want to build for maintainers to seamlessly be able to tap into and upsell to their audience to get more backers for those services.

Brian: Okay. Yeah. That makes sense because I guess a lot of GitHub folks would know this, but we shipped GitHub Sponsors quite a few years ago and there was a huge push like 2019, 2020, around the creator economy. Even more so in 2020, 2021, especially when Patreon raised whatever their last round of funding was. But GitHub, it's an interesting place because it's a bunch of creators but no one thinks of themselves as content creators because if you have to be an influencer on whatever social media platform, it kind of detracts away from you shipping code.

So I think I saw a tweet earlier today about someone saying, "New developers, you don't need to be an influencer. Just learn how to code, and that's it. Create content when you're ready to create content, but learn how to code first," because there's a huge drop off of folks coming out of boot camp and going to DevRel and not getting the actual skill of being a developer.

But I guess what I'm getting at is GitHub is full of content creators, but the tooling has always been lackluster. I know the GitHub Sponsor scene, I know you listen to this podcast because you're a fan of me and I'm a fan of you. But it's always been a goal to get to that point where you have more tooling for creators, maintainers, creators, I'm using them interchangeably.

But there is a special maintainer who can create and deliver content, and those folks have figured it out. But there's still a pathway for folks to level up, and I think with your future vision, your long term vision, it makes a ton of sense and I can see a lot of future synergies with folks on GitHub. But honestly, my question would be does it stop at GitHub?

Because obviously Replet does also have a huge community of I guess Gen Z developers, I don't know. It's a different wave of development, but it's a community that everyone should be paying attention to right now.

Birk: 100%, as well as Hugging Face is another one, or you have GitLab as well. Our goal of Polar is definitely to be a platform that can support all of these different platforms where you're hosting your code and collaborating with your communities.

I think the difference there is to go back to the point around GitHub, is I think this platform around being a creator or an entrepreneur or running a business or your own open source initiative, is very much a platform that is on top of where you're running your code and running your pull requests and collaborating with your community.

Because there's so many unique features we need to build around how do you manage accounting and taxes and so forth around it, so that's what Polar aims to build and be, that platform and service you as a maintainer regardless of where your community is based today.

Brian: Yeah. That's exciting. All my interests, they align with where Polar is going and I think you're onto something there, for sure, 100%. I think the folks that are listening to this and the folks that are doing stuff, really cool things in the open source should definitely check it out, for sure. I kind of ran through all my questions, what else did you want to cover as far as Polar and feature set and things that people should be paying attention to?

Birk: Well, I think one really important part is the fact that we're building Polar open source ourselves. Our entire codebase is live on GitHub, PolarSource/Polar under the Apache 2.0 license. The shameless plug here is if you're an open source maintainer and you're excited about this vision and what we're building towards, please know that we're building this in public, in open source and we would love to have you join that journey and help shape our iterations and how we get there long term. We're really building it for maintainers, so join in on the fun on Discord and on our GitHub to help shape the future.

Brian: Yeah. What's your thoughts? I guess I have an answer, but I'm curious on your thought on why you chose Apache 2.0?

Birk: Yeah, that's a great question. Open source licensing is a podcast topic all on its own, right? The short answer is we wanted a permissive license and I went with Apache 2.0 because it's one of the more standard licenses out there that everyone's very, very comfortable, they know it intuitively by heart today.

I think there's some challenges with Apache 2.0, which is of course that someone could just fork this repository, build a proprietary solution on top themselves, as a competitor. But ultimately I think for Polar to become successful, it's more about building this community and a platform for maintainers, rather than the IP and the code itself. So that's why we went with the Apache 2.0.

Brian: Yeah. I think the Open Sauce name is something I'm very proud of, but also there's a lot of name conflicts. We went 2.0 as well, and honestly I just copied Superbase because I figured, "Okay, what are Superbase doing? They're having some success over there." But yeah, the licensing thing, it's a thing that I don't want to put too much thought into because I don't want to become a lawyer, but it's something that everyone should think about once you have a little bit of success from open source and how the project basically lives in the ecosystem and out in the open.

Also, it's one thing I've come up recently, especially selling your open source project as a cloud offering, folks do look at the license and want to know what this is going to look like, and what is success or they get value from your product. Can they continue to go down the path of value or does this hit a ceiling because of a weird, I don't know, random Facebook Meta license that was attached to the project.

Birk: Exactly. Especially now with the open source supply chain and all the software around that for larger enterprises where they're scanning these licenses automatically. There's a debate to be had there, I think there's a lot of innovations on the licensing side which is amazing, like the BSL for instance. But typically the OSI licenses are the easiest to go with to create the least amount of friction if you want to sell to larger companies or enterprises.

Brian: Yeah, 100%. Sometimes you got to do a little bit of pattern matching and fit within the framework. Speaking of framework, I know there's a bit of a conversation, sorry, moving away from our original conversation. But there's a tweet that actually went out yesterday around Stack Overflow and the trend of folks who are leveraging Stack Overflow over things like ChatGPT and other resources.

But the trend is pretty shocking, from 20222 it's a downward curve. I'm curious to hear your thoughts on that, and where everyone leveraged Stack Overflow as a knowledge base for developers, but now they're just going other places. I personally think it's on the creator side where folks are answering questions in different places, but I'm curious to hear your thoughts and if you saw that tweet go out.

Birk: I didn't see the tweet. Unfortunately, as a trend it doesn't surprise me that much. Just noticing my own pattern, I think ChatGPT or CoPilot that I'm using, just automatically ensures that some of the questions you run into are basically automatically answered by CoPilot as you're coding away.

But also as we're building Polar open source, I have noticed whether through issues or contributions that there is this very beautiful back and forth between the maintainers and the community. In some of those cases there's developers that are probably more on the junior side that are still doing great contributions, then you can help educate them a little bit as they're doing their review of the pull requests which is a win-win for both sides. It's been amazing.

Brian: Yeah. Yeah. I agree. I dropped the link to the tweet in the show notes. My thought is you take an open source library, the person who created a thing, if they could have the tools to explain the thing and answer the questions. I think also there's another trend, GitHub Discussions also made this where a lot of those answers are now in house next to the code. Obviously Discord is a whole nother tool as well.

But there's other places to get answers, and I think going back to even my mention of Replet and even TikTok developers, specifically developers who do TikTok videos. There's a new form of education. I think I actually need to spend the weekend using TikTok as a search engine because I just wanted to see something done.

I know everyone is doing AI, and I know there's an example somewhere on TikTok, like, "Here's my 30 second build a thing," and I just want to see the video. I just want to see someone type. I think that's the benefit of everyone is now remote, I don't sit in the room. I was lucky enough to sit in the same room last week with my engineers, and we just cranked out some code together.

But we all have to get on a plane to do that, you got to plan sessions. So now I can get that experience of looking over someone's shoulder by the content they create. I think tools like Polar, I guess what I was getting at is tools like Polar, if you build the pieces for people to be successful and distribute information. I think even before I even hit record it was the challenge of being a founder and even talking about your product, and having a framework to consistently give change log or updates.

All that type of tooling is extremely needed because I think we spend a lot of time looking at trends. When I was at GitHub, but also what I'm doing now, projects that are up and coming and all the projects that either take off either have... they're simple enough that anybody can understand and use, or it's got good marketing.

So there's a readme, there's a docs page, there's infrastructure for people to be successful, and that unfortunately is where success lies in open source today. Not so much the case 20 years ago, but today if you have a little bit of a brand or a little bit of a sticky situation, people will come back for it.

Birk: Yeah. No, absolutely.

And I think that's our mission and goal with Polar, right? It's to basically equip maintainers with all that tooling to help them leverage these aspects of becoming a creator within open source without that becoming an overhead or a bottleneck which it is today.

Just remove the entire friction and then for maintainers to experiment with what works for them, and I think the important part there is what's different today from so many years ago is as soon as someone starts to become successful within any given domain, they start to become a leading examples for others on how you can achieve the same type of success.

So hopefully that is something we'll see with Polar as well, that we can enable a lot of these maintainers and they can in turn make sure this becomes more of a common and normal thing within open source.

Brian: Awesome. Amazing. Yeah. Birk, thanks so much for the conversation on Polar. I do want to transition us to picks. Folks, definitely check out Polar.sh if this is all interesting to you, or at least tell a friend about it. So Jam picks, these are things that we're jamming on, could be music, could be food related, could be tech related.

If you don't mind, I'm going to go first. I've got a pick that I actually started, I've been looking at this for a while and I've been talking to the creator and the maintainer so it's also open source. But if you're familiar with Bit.ly, Bit dot L-Y. Someone has created Dub.sh, which is an open source Bit.ly. You have the choice, you can self host this and I think it's...

Well, I know it's a Vercel T member, so self hosting on Vercel and they do serverless functions to do the link tracking on the stuff. It's pretty nifty software. A decision we had to make at Open Sauce, do we build this ourself or do we just use Dub.sh? So the obvious choice is do we use the thing that has a community and that's open source, so we're doing that, and so far so good.

We have this URL which is OSS.FYI, and we haven't done this yet because the API hasn't shipped yet but the beauty of this being open source we can track and call a log, and help provide some support and feedback. But then we're going to use the hosted version when the API gets shipped as well. The goal is that any shared link off of Open Sauce will have an OSS.FYI link and there'll be a short URL or a short code.

I'm super excited about this because it's a thing I've built a few times, not as well, but to be able to work off the hard work of Steve and Tay who built this, I'm super off the moon. Speaking of which, creators, maintainers like Steven, Hasam, the Vercel team, they're shipping a bunch of really cool projects and doing them out in the open. I think they would be really good candidates for Polar because it's all side work, nights and weekends for them.

Maybe actually... I don't know, maybe I over spoke, maybe they might be doing this for their day job as well because they're selling deploys on Vercel as well. But yeah, what I'm getting at is I'm looking forward to just getting started with this engagement with Dub.sh. Definitely recommend people check it out. Have you used it at all or taken a look?

Birk: Yeah, I have. I think Dub.sh is an amazing product. Steven, his velocity is just insane. It's so inspiring, and the product is both beautiful, open source and really well executed. I love the domain OSS.FYI as well. Can't wait to see it.

Brian: I actually talked to Steven a couple of years ago, we were at some random dev dinner. He was having a conversation of, as DevRel, should he just go speak and do a bunch of meta stuff? I don't want to attribute his success to me, but I remember telling him specifically, "Steven, you need to ship more examples. That's your skillset, there's no need to go into a bunch of other random stuff."

I think in DevRel, sometimes we get a little lost in the sauce, thinking we have to go travel the world and create a YouTube channel and do everything. At the end of the day, it's just getting the examples in front of the developers so that they can be successful on your platform.

The entire team does a really good job on that, so shout out to the Vercel DevRel team. I did have one more pick which is the tool we've been using for, man, eight years to record this podcast which is Zencaster. Zencaster has just updated the UI which kind of threw me off this morning, but if you are looking to record a podcast I just want to shout out Zencaster because they've been tried and true.

Pretty much no downtime, I think we had one issue years ago when Apple shipped the Airpods and the Bluetooth technology would not work inside the Chrome browser without interference. But yeah, as an early adopter that was figured out and super grateful for the team and what they've done for the past... Well, they've been doing this longer than eight years, probably 10 years at this point. But I've used them for a previous podcast and brought them to Jamstack Radio.

Birk: First time I'm using it, but I love the experience as well from someone joining in on my end.

Brian: Excellent. Yeah, any picks you got?

Birk: Yeah, I have two picks. Bit geeky in nature. The first one is a new newsletter called Dot Files by Adib Hana. I found this just a couple of weeks ago and I think it's only been around for a few months, but it's essentially a weekly newsletter. I think it's weekly. It's where Adib is interviewing developers about their Dot files and their development setup.

I just absolutely love it, I look forward to it every single week and I always pick up some new gem that I can pick up into my own toolkit. The other one in the same vein is The Tech Show, by Will MacGuigan. Sorry if I'm pronouncing his name wrong, he's from the Textualize team. Will built Rich, which is an amazing library if you're building anything for the terminal command line interfaces, to do them prettier and more of a user experience.

Now they're building Textual which is just blowing my mind on a daily basis on Twitter, what they're able to do within the terminal and what this library in effect enables others to build within the terminal.

Brian: Yeah, I was going to ask, Textual, it sounds familiar. Can you explain a bit more of what they're doing?

Birk: I think if I remember correctly, their pitch is if you're a Python developer and obviously Python is a language that's very, very popular across many developers, you can develop applications for the terminal and even for the web purely using Python and in a very, very seamless way, without you having to bother too much with the nitty gritty of the UI within the terminal.

They're shipping a lot of awesome stuff, basically on a daily basis and the apps and tools that people are able to build and what you can see now across the community are really awesome to see.

Brian: Very cool. Yeah, just taking a look at the website, this is absolutely magical. As someone who's currently working on a CLI tool, there's some inspiration here.

Birk: Yeah, for sure.

Brian: Cool. Well, Birk, thanks so much again for the conversation and the picks, and, the listeners, keep spreading the jam.