I could very much be wrong about this, but the whole thing feels like it's coming from the perspective of someone thinking "I've heard about OSS, let's see how I can monetize it", rather than "I've participated in the OSS world for a long time, and I have an idea that can improve it".

It doesn't seem logical but I hope someone can pull it off!

I would like to learn more about the background of the founders - what they've already done in any way related to this. Why does Polar have a chance?

The problem is that I don't know if people/businesses are really willing to pay the actual cost of getting things done.

I'm not even sure people even appreciate the work that is involved in most of their requests - how many times have you looked at some commercial software and had the "could build that in a weekend" reaction.

My other concern is around expectations. I've always tried to be very clear with any donation type thing that it's a donation. There's no obligation created on my part to provide any services or support. Directly coupling payments to requests might turn this into much more of a "I paid you to do this, why isn't it done yet".

There’s a secret third thing that never seems to get mentioned: not pittances through donations and not speculative investment from VCs, but plain old paid engineering. Most open source maintainers don’t want to be “entrepreneurs”; they just want to be paid an (approximately) fair rate for their time. Hiring them (or paying them for consultation time) achieves this.

https://github.com/joelparkerhenderson/architecture-decision...

(I'm on the fence about the value of Polar for this kind of issue... see what you think)

I have some questions:

1. Can anybody place a bounty on any issue? That seems like it could take control away from the maintainer. Is there a way for a maintainer to reject an issue bounty, so they can keep control over the direction/architectural decisions of the project?

2. Could someone pledge money towards a milestone (e.g. the next major version) rather than specific issues?

3. Are you offering any kind of business support to maintainers, such as reaching out to business users on their behalf to negotiate a sponsorship/support contract/bounty/etc? The sales part of all of this seems like it's the biggest challenge for OSS projects where it's just a few engineers who don't have the time or skill to do sales.

From the article I didn't understand the model. Or how it is diffirent from existing projects like https://bountysource.com/ and others.

If I wanted to be a social media influencer, I'd be on Instagram / OnlyFans.

If i wanted to spend my time "an entrepreneur with superpowers to convert the community into backers", I would be running a company / start up doing sales.

I wish to write code.

Some of that code is open source. Some of it I write because someone pays me to do so.

I dont have to do any sales and that is fantastic.

So far nobody has given me money for my open-source code and that is fine.

I write my open-source tools because I admire those who came before me and all they have contributed to the world. It is a civic duty.

They gave us operating systems, compilers, databases, libraries.

When someone creates a new thing and its 90% derived from free tools with a bit of code sauce / UI on top it, call it open source and then run around wanting to get paid for it they are in the wrong pasture.

If you are wanting to make billions of dollars and you create some form of "open source" system but you get angry if someone uses it and does make money from it, you are in the wrong pasture.

Contemplate Linux, (Open)*BSD, GNU tools, Postgres and everything open source you use to make your product and none of which you have paid for. Imagine if Theo had $1 for every OpenBSD install. (I love OpenBSD) Id owe him at least a few hundred dollars. On aggregate he would be at least a millionaire.

For people who do want to inject money into open source that is great. Dont pick me.

Pick projects that are vital in the stack and who are underfunded.

For example, I want to donate $100 toward Rust Rocket version 1.0.0.

Can Polar help with this goal? If so, what's my next step?

However, I don't see how this is not fundamentally just a Github feature. They don't have it now, but if Polar gets any traction, they'll implement it pretty swiftly and probably eat your lunch.

Yes, obviously donation/sponsorship doesn't work, but I'm not sure pay per issue resolved is the best model either. Good apps shouldn't be punished for having few issues, or needing few features.

People should be able to opt in, but I think opting in at the distro level is the right choice as it would create a broad base of support. Of course, there will be those that don't want to pay, but I think a premium model for power users and enterprise customers makes sense. These premium users could have access to beta/nightly channels, early SRPMS/src debs, and priority or triaged issue/PR resolution?

Are there issues to be resolved? Yes, of course. How to divide payments to apps, and within app communities, but these aren't insurmountable problems. Canonical, etc., could simply set standards and require app communities to explain any variance from those standards.

The big BUT is that software needs to be maintained whereas a video once uploaded on YouTube doesn‘t need to be edited again.

I have a feeling that Birk and the Polar team have the right insights to build the right tools to serve the specific needs of open-source software maintainers.

A company might want to buy 1000 tokens and allocate tokens individually to specific issues, but they also might want to put tokens in a pot the maintainer can access to "spend" on issues they want to prioritise for the project or allow them to "spend" tokens at a specific rate, etc.

It also means that money is committed upfront by the companies, i.e. the money is real and exists, has been set aside for this thing and in case of a dispute polar can make decisions, etc

Edit: to expand -- these initiatives seem to always be cooked up by people who do not write software, don't fix bugs, don't hire software developers. They never work because adding a feature to a product or fixing a bug isn't a commodity item that you can just buy with a click and spread cost between many parties.

The result is that most of the prospective purchasers end up having an easier path to get what they want, which is to fork and fix themselves (usually via in-house devs already on staff).

Conclusion:

> Bounties are a lousy foundation for sustainable development of large projects like FreeCAD. They typically represent a gross underestimation of real work required to solve a problem, commonly miss a bigger picture, and encourage worst software development practices.

Growing larger is fun but also really overwhelming. Most ambitious projects that aim to stay afloat will have to experiment with different approaches to getting funded on a regular basis and come up with their own mix of solutions. It’s that or perish.

>Join our Discord to discuss ideas, early design proposals and upcoming features

Yeah, no...disheartening to see this many FOSS developers opting for Discord for realtime chat.

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.

Good luck to the founders, it’s a worthy problem.

Business accomplishes something non-profits haven't isn't exactly a stop the presses event?

- registering a business entity costs money and (especially in dysfunctional bureaucratic hellholes) time

- you can be held completely liable for whatever you offer if you don't take excruciating care with the legalese fineprint

- it's a complete nightmare on tax filings (e.g. in Germany you can't have your taxes handled by Lohnsteuervereine if you have a side business, i.e. income from sources other than regular employment)

- you often lose anonymity because PayPal discloses your real name to everyone knowing your email address, or SEPA payments requiring your name

- people can and will fuck with you just because they can or because they hate you for whatever reason. Anything from mass reporting you to Paypal over death threats to outright SWATting you.

As an oss maintainer, the way I see it is that unless the purpose itself behind the oss code is to make money via consulting, offering consulting is usually not in the interest of the people behind the code.

It is oss, after all. Other companies can form around the project and provide consulting support.

Of course that isn't the case for all projects, but you can't always assume that the maintainer is willing to accept payment if you are willing to give it.

I think a better model might be to have consultant companies that employee people to fulfill bounties on various projects, and possibly handle building and distributing custom forks if the upstream maintainer is unresponsive (or just takes longer than the customer wants) or doesn't want the change upstream.

ooo, ooo, I know... (hand up) - pick me... pick me... Short answer, no the're not.

The ones that are demonstrate their willingness to do so by, you know, spending money on proprietary software. I'm as happy as the next guy to make use of Open Source software, but it either works for me (no money necessary) or it doesn't (in which case I'll spend the money, with, you know, an actual business...)

Ok, cynic mode off, but let's be honest - there's a new "solution" to this problem like every other week. They all want to funnel money between the mythical person who wants to pay, to the mythical developer who wants to receive. All the other methods have failed, but apparently the problem is not the lack of people _willing_ to pay, but the fact that it's "too hard to pay"? I gotta say, after all these attempts, you would think one of them would have succeeded, unless, perhaps, aside from a few anecdotes, the actual pool of payers doesn't exist.

I wish you well, I really do, but I fear you're solving the wrong problem. Trouble is the right problem isn't solvable. But maybe, just maybe, if you solve the wrong problem enough, then maybe something of substance will happen.

I could go on about how most OSS developers don't _want_ to be paid. Because getting paid tiny amounts is a hassle which exceeds the income. So sure, guarantee me 10K a month for more than a year, and maybe it's worth the effort of accounting, and taxes, and obligations, and deadlines, and people complaining after the fact, before the fact, during the fact. But for a few hundred $ here and there - pass...

Cynic mode back on - another month, another startup planning to solve this "problem". Good luck!

1. Sponsorship is hard to sell internally. Only possible to get small budgets with the motivation of advertising towards developers (be it their product or hiring).

2. "We'd love to invest more, but we don't know towards what, what it will be used for and how that in turn benefits us which is needed to unlock more capital internally".

3. Once I pitched Polar, they got excited about how it could address #2 and all mentioned cases where they had been blocked by OSS issues or where they had feature requests. Not being able to address those themselves.

There is a lot of unnecessary friction today to sponsor specific features, issues or milestones – despite such being a lot easier to sell internally because they're tied to businesses needs. Polar aims to change that + gives maintainer(s) complete control to ensure it aligns with their goals and direction of the initiatives.

> I'm not even sure people even appreciate the work that is involved in most of their requests

Absolutely. I think this is solvable though, e.g giving maintainers the ability to set goals for certain features, milestones or issues being one.

But, we cannot expect it to match an hourly salary as a paid engineer from Day 1. It's a new pattern. However, since maintainers are in complete control (it's not a traditional bounty service) sponsored issues that are accepted should align with efforts the maintainer wants to pursue too. Before they got $0. Now, they better know what their users want and can get them to sponsor efforts that align with theirs.

> My other concern is around expectations. I've always tried to be very clear with any donation type thing that it's a donation. There's no obligation created on my part to provide any services or support. Directly coupling payments to requests might turn this into much more of a "I paid you to do this, why isn't it done yet".

Completely agree.

With Polar, maintainers are in complete control. They can decide which issues they want the Polar badge to be embedded on to whether the amount pledged is shown or not (since it can apply such pressure). In combination, we don't have this feature today (early alpha), but we want to make it super easy for the maintainer to accept/deny pledges in their admin. To setting thresholds and more, as mentioned earlier.

Our goal with Polar is to empower you as a maintainer and give you all the tooling to manage this with ease.

Open source operates in a marketplace today (just not an economic one) so market dynamics would flush this out imo. Intentional bugs, stale development etc would lead to user churn and/or forks. I'd argue faster within OSS where users can see how things are handled.

Having said that, I certainly think the risk of it and fraud more in general increases once an economic marketplace is formed. However, I think those problems are then "good" problems to have and easy ones to fix, e.g flagging repositories with unusually high ratio of repeat pledges, velocity of bugs etc.

If a project became notorious for pulling stuff like that, and rejecting pull requests, people would most likely just make a fork.

I guess that also raises the issue of who gets paid if a third party pull request fixes an issue.