That would be me :-) My name is Birk Jernström (@birk on Twitter). Been coding since I was 10y. Co-founded an e-commerce platform called Tictail back in 2011 which was acquired by Shopify in 2018. Worked there for 3y as Director of Product on the Shop.app team. In hindsight building platforms that empowers creators (one form or another) is what I love to do. As a self-taught developer thanks to open source, I'm incredibly excited to now focus on OSS with that mindset.
I'm biased of course, but I think the fact that we're VC-funded and for-profit is a good & important difference here. Donations & sponsorship are great when they happen. Problem is they rarely do. In order to drive meaningful (full-time work) capital to OSS initiatives, I believe it has to charge for add-on value and that such services and subscriptions are mutually beneficial. See mkdocs-material as a prime example.
We're building a platform to make setting up, deploying and managing such services seamless for both maintainers and their customers. Completely up to the maintainers to craft their services & subscriptions using those features to fit their initiative & community. I think such a platform is missing today and our model aligns us with maintainers – we don't get paid until they do. So it's good that we're intentionally for-profit :-)
Yes, it's going to be incredibly hard and the odds are stacked against us, but I believe this needs to exist. Maintainers deserve a platform where they are not limited to any given model, but free to experiment, try and optimize what works best for them and their communities.
Then I hope you provide a better system for dealing with (or allowing the maintainers to deal with) taxes. Unless the maintainer of mkdocs-material somehow funnels the earnings through a US company, I'm almost certain that it's impossible to offer what they offer while being based in Germany without violation tax rules (as what they are offering is clearly a sale and not a donation, and Github doesn't issue any sales tax).
That's one way to do it, but it's extremely challenging. The sales tax can depend on where the buyer is located, where the buyer is from, where the seller is located, and where the seller is from. There are ~1000 jurisdictions for each of those four choices, so that makes for ~1000^4 different cases to handle. You'd also have to register as a merchant in each juridiction, and know the rules for when you have to start remitting sales tax to that jurisdiction. There are whole businesses built around managing that complexity, e.g. Avalara, Vertex and TaxJar (now part of Stripe). Maybe just offload that burden to one of them and focus on building your core innovation.
> Maybe just offload that burden to one of them and focus on building your core innovation.
I don't think that's incompatible with their model. They absolutely could use Stripe to accomplish this transparently and not sacrifice any user experience.
Yes, absolutely. Polar is built with Stripe today and will continue to be – leveraging Stripe Tax and additional offerings they have as we scale to build compliant & great user experiences at the same time.
Yes, as we expand into services that will be key. Working with tax lawyers both in the US & EU along with Stripe to make sure we make it easier for maintainers than what it is currently via other platforms.
> I'm biased of course, but I think the fact that we're VC-funded and for-profit is a good & important difference here.
For-profit is not necessarily a problem here; the VC-funded part it.
How on earth are you going to extract enough value out of it to generate a ROI that VCs are expecting? As a purely bootstraped company this could have legs, but as a VC-backed company? I'm very doubtful.
Sounds awesome! Love your idea, but I was wondering as to what would happen if GitHub built this into their platform directly, bypassing Polar. What does Polar have that GitHub doesn't, in case that happens?
Thank you xNeil! Focus & velocity is key. This roadmap is our #1 priority, sole focus and ultimate business. It would be GitHub's #1058 priority – if ever.
I love GitHub. They're the foundational layer of development in the ecosystem. However, an economic platform like Polar's intentions long-term is an entirely separate layer on top imo. Requiring a whole suite of different product offerings and operations tailored to it. Such as taxes, accounting, payments, customer management & communication to supporting platforms beyond GitHub, i.e GitLab, Hugging Face and more. Sure, there is overlap, but mostly the two are separate layers with substantial requirements of their own.
GitHub should focus on their core layer of development. It's massive and ever changing (especially now). Offering users to expand their "hub" through app integrations and partnerships. Combined with leveraging their investment arm & rev share with third parties – as all other platforms – to gain upside in other economic models/layers built on top. I think that's the better and more likely strategy for GitHub to continue on.
The reason I'm asking is: I believe VCs increase the risk of enshittification.
Incumbents that employed a "pay a bounty for maintainers to fix the issue" model would simply pocket the bounties for issues that never got picked up. Is this a risk for yours too?
It's 100% the responsibility of the founders and leadership.
I think enshittification is more a consequence of either 1) current metrics not matching costs 2) loss of long-term vision of further innovation (often once it's no longer founder led) 3) no competition.
It's either an attempt to make up for the bleeding short-term (1), unclear path of expansion (2) or an excessive ability to maximize costs due to no alternatives on the market (3).
In many ways, I'd argue VCs decrease the risk of enshittification or delay it. They're comfortable funding the delta between current metrics vs. costs (1) – up to a point, of course. They also love to fund competition in proven markets (3).
> Incumbents [...] would simply pocket the bounties for issues that never got picked up. Is this a risk for yours too?
This is a combination of the problem not having been solved at scale and of such actors needing cash (1). At Polar now, we have runway for years even without $1 in revenue – thanks to VCs.
Of course, I understand what you mean and ultimately the problem in our industry arises when "the party stops". At some point current metrics & costs need to balance. However, I'd argue this is the responsibility of the founders. VCs will always be the voice of "invest in growth" because it's fundamentally what their capital is for. Founders need to know how to leverage it, track current metrics and obsess about how things are progressing to match up eventually and spend + invest accordingly. Combined with having a long-term mission & vision spanning beyond quarterly goals. Enshittification is duck tape for lacking these things and ultimately fuel for competition.
So to answer your question, I believe I'm to be held accountable and not VCs in case we enshittify the product. Having worked at Shopify, I'm inspired by their 100-year mission and being founder+product led and obsessed about merchants – knowing money comes as a reward and is not the pursuit. Having also started a company before, I've learned to "not get drunk" by the party.
We're building towards something new in the pursuit of creating an independent pathway towards careers and small businesses within OSS for those who want to pursue it. It will take time and it will cost a lot of money to make this bet. It would have been impossible without VCs and I've chosen really great ones who align with this mission. I'm beyond thankful for them making this possible because that's what it boils down to.
I'm biased of course, but I think the fact that we're VC-funded and for-profit is a good & important difference here. Donations & sponsorship are great when they happen. Problem is they rarely do. In order to drive meaningful (full-time work) capital to OSS initiatives, I believe it has to charge for add-on value and that such services and subscriptions are mutually beneficial. See mkdocs-material as a prime example.
We're building a platform to make setting up, deploying and managing such services seamless for both maintainers and their customers. Completely up to the maintainers to craft their services & subscriptions using those features to fit their initiative & community. I think such a platform is missing today and our model aligns us with maintainers – we don't get paid until they do. So it's good that we're intentionally for-profit :-)
Yes, it's going to be incredibly hard and the odds are stacked against us, but I believe this needs to exist. Maintainers deserve a platform where they are not limited to any given model, but free to experiment, try and optimize what works best for them and their communities.