Hacker News Reader

Yeah, has been tried a few times. I only followed Bountysource closely-ish, but they ended up taking a lot of money and then that money sat in bank accounts indefinitely because it often didn't lead to issues being fixed. I heard that eventually someone bought the company for peanuts and drained the bounty accounts, despite promising that they definitely wouldn't do that.

The problem as I see it is that a lot of those bounties are $2,000 for $20,000 worth of work, especially since they end up getting attached to the most gnarly bugs whose true solution involves deep refactoring or building essentially whole new products. Thus the maintainers need to be willing to support the features indefinitely, and they need to agree with the architecture of the solutions, and quite rapidly you start to understand why a little cash is not sufficient to solve the most intractable problems.

Hello, and thank you for your feedback!

I appreciate your concerns, and we've thoroughly examined BountySource and learned valuable lessons from its challenges.

Our approach involves collaborating with corporations that already leverage open source projects for their enterprise software. By having these companies donate funds to critical issues, we anticipate larger sums being contributed to open source causes than might occur otherwise.

While we recognize that we don't have solutions for every challenge in this space, we firmly believe in the ongoing involvement of open source repository maintainers in our donation process. We are committed to innovation and plan to adapt and improve with the help of the community using our platform. We encourage the community to actively participate in finding solutions for these challenges, as we believe it can lead to a sustainable model that brings significant value in the long run.

Thank you again, and we welcome any additional feedback you may have.

Corporate speak is strong with this one.

I'm not sure you addressed the point: one-time donations do not solve the problem of companies trying to get free labor over time, even if they are larger donations. This is a problem that has to do with scoping, and setting the right expectations for companies, contributors, and maintainers.

Possibly related: some issues might be cool and interesting to work on while others are dull and boring. A lot of times the former becomes the later after getting passed the MVP stage. This might create an abundance of contributions that are flimsy, and that nobody wants to maintain over time for peanuts.

I think it's cool you all want to get this eventual community involved but you gotta provide the solutions to the most foundational challenges, otherwise how are you adding value in the market?

Hey, thanks for your thoughts!

We've put a lot of effort into thinking about potential issues and talking to potential users, but the real test will be when people start using our platform in the beta phase.

We have some ideas to solve problems, and we'll be trying them out gradually as we learn from the beta testers. Your feedback is really helpful, and we're sorry if we don't have all the detailed answers just yet. Thanks again!

I like the site, but I feel like this has been tried a few times. Gotta be a bit direct here: Is there a business model here beyond hoping companies will play ball and donate through OpenPledge? "secured investment" just sounds like "we have initial runway to burn".

Hi there! Thanks a lot for sharing your thoughts. I completely understand your concern about the business model, and it's a valid point. Our key differentiator lies in our focus on issue-based donations rather than contributing to entire projects. This ensures that the funds directly benefit the actual contributors.

As for company donations, we are actively building personal connections with initial donors. We believe that having established collaborations with well-known entities will instill greater trust in the community. This approach aligns with our strategy to showcase tangible partnerships as we grow.

Additionally, we're taking a unique approach to entering the market. Our initial strategy involves concentrating on one technology stack at a time, such as exclusively covering JavaScript. By doing so, we aim to influence and reshape the culture within that specific open source community. After we will have one community covered we will slowly spread to other branches :)

We recognize the inherent risks in this endeavor, as with any ambitious project. However, we are optimistic and fully committed to giving it our best shot. The initial investment serves as a necessary head start to help us lift off smoothly.

Your support means a lot to us, and any encouragement from the community is highly appreciated as we embark on this exciting journey. Thanks again!

I completely agree with the idea. But you should have waited until you had something to show before promoting. Right now there's nothing there.

Hi there! Appreciate your feedback!

We understand the value of having something tangible for the community to try. As a startup actively working on our beta version, we're working hard to gather a group of early adopters to test our initial version and validate the platform functionalities. That's why we're encouraging you to subscribe to our "waitlist."

Your support is crucial to our development process, and we appreciate your patience as we work towards bringing a meaningful and functional platform to the community. Thanks once again!

How is it different than GitHub Sponsorship, Patreon, Bountysource (I feel there's a couple more of these...)?

Hello!

You're absolutely right; there are already platforms enabling users to donate to open source projects or various services.

Nevertheless, the concept of donating to specific open source issues and rewarding the person who resolves those issues isn't widely popular on existing platforms. While Bountysource came close, it never quite reached its full potential. We believe that a slightly different approach, with an emphasis on smaller communities initially, can make a significant impact.

Thanks again for your feedback!

Cool project, I really like the idea of sponsored issues. But what happens to your company, if GitHub decides to adapt this feature?

Hello, and thank you for your feedback!

As a startup with a current team of two, we pride ourselves on being highly adaptable and agile. Our goal is to experience rapid growth and redefine how people perceive open source support. By achieving this before GitHub identifies the opportunity and begins development, we aim to cover significant ground, making it less viable for GitHub to launch a similar initiative.

We acknowledge the inherent risks but are determined to be innovative and swift in our approach to ensure success. Additionally, the open-source market is vast and expanding rapidly, further fueling our optimism about the potential for our venture.

I disagree on the sponsorship of issues being a good idea. Let's say there's an issue that's complex enough to warrant forking over several thousand dollars to cover the development cost. This will inevitably lead to a non-trivial amount of code being written. Who maintains that code in the future?

Any open source project adopting this model for funding will be in a perpetual cycle of chasing features and the rapid deterioration of code quality that comes with feature-driven development.

On the flip side, if a project opens an issue for "resolve security issue X" and refuses to ship a fix until it is paid for will be seen as holding the release hostage, resulting in a whole lot of negative press even though shipping a release can also be a serious amount of work.

Hello! Thanks for sharing your thoughts!

Our research indicates that many repositories could avoid abandonment with more targeted funding, which is why we introduced the issue-based principle. However, we acknowledge that this approach may not be suitable for all issues or open source repositories.

To address this, we're considering giving repository maintainers the ability to manage donations, such as distribution and permissions on specific issues to encourage proper development. The actual execution of these features will be tested during the beta phase, as predicting their usage beforehand is challenging.

Your feedback is valuable, and we welcome constructive criticism and ideas. Thanks once again for your input!

> resulting in a whole lot of negative press

How exactly would somebody receive negative press for not working for free? Microsoft doesn't get bad press for charging money for Office. Programmers don't get bad press from asking their employer for a salary.

Even assuming there would be some "bad press" – so what? Open source users give nothing back to the developers anyways, so there's nothing they could take away.

I'm not saying it's right, but a lot of people feel like open source means they are entitled to everything from getting binary releases, documentation, their bugs fixed on time, their feature requests implemented or their (sometimes deficient) PRs reviewed and accepted. All in need of careful communication which is easy to mess up.

A project that finances their development through getting paid for features will have to balance how much time they spend on paid vs. unpaid work. Getting maintenance work paid is hard.

I'm interpreting that you're comparing paid open source work vs closed source work, am I understanding it right? Between those two options, closed source is always the better option.

Not at all, but we are talking on a submission about getting open source work paid. I've done my fair share of unpaid open source work and it was a ton of fun. I've had a lot of very good experiences with the community coming together to resolve an issue, but I've also had bad experiences, mostly with larger entities consuming said projects and not willing to contribute in any way, shape, or form.

With that premise, recently I've experienced more and more release engineering asks popping up around open source: SBOMs or other compliance reports, regular dependency updates (dependabot and friends), regular releases, support cycles, supplying a DEB/RPM/APK repos, shipping on Snap, Homebrew, Winget, Chocolatey and who knows where, sign with cosign, GPG, x509 and so on. You get the picture. I have yet to meet an engineer who likes to do release engineering in their free time. It's hard to test, it's hard to automate and is super sensitive because if you mess it up you leak keys or compromise user systems.

This is something I believe the poster needs to address, otherwise their platform will be full of projects doing feature-driven development with important safety and maintenance concerns left by the wayside. Although I have seen a few working models, I don't know the solution for all of open source. I believe that if we are talking about viable funding models, funding needs to address both feature and maintenance work and not tip the scale too far in one direction.

I still don't really understand the point of view. If the open source programmer don't want to do all these boring things you mentioned, they don't have to. If somebody has a problem with that, they can fork and fix it themselves, or offer to pay the programmer to do it. The unpaid open source programmer does not have any responsibility towards anybody else. Safety and maintenance is not his responsibility, it's the responsibility of whoever is using the software. If security is crucial, then they should inspect the code or pay for audited code, for example some closed source software.

I imagine a paid open source model to be where I and other users can offer money for features or bug fixes we need. The best implementation would be that users could each pool a small amount – "pitch in" – for features. Honestly, it wouldn't even have to be open source. Let users who are willing to pay developers have their say and make independent programming more sustainable. There are endless good consequences. For example, backwards compatibility might not be interesting for the open source programmer. With a bunch of users willing to pay for this, then it might become worth his time. Or language support, different platform support, special integrations.

And if the original developer is not interested in any paid work, then other programmers could fork and implement. Honestly, I think that users shouldn't even be allowed to raise an issue on Github or such places without offering monetary compensation. Fork or pay or die should be the motto.

Small nit, but while the page is in English, the label for the EU under "Powered by" says "Europska unia".

Hey, our investors provided us with the specific content that we needed to include. Thanks for noticing anyway.

Show HN: OpenPledge – Make a career with Open Source contributions