5 ms·

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

by d4ve-r 3y ago

zigcBenx 3y ago
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.
janosdebugs 3y ago
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.
- zigcBenx 3y ago
  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!
- carlosjobim 3y ago
  > 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.
  - janosdebugs 3y ago
    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.
    - carlosjobim 3y ago
      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.
      - janosdebugs 3y ago
        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.

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

by d4ve-r 3y ago

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

zigcBenx 3y ago

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.

janosdebugs 3y ago

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.

zigcBenx 3y ago
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!
carlosjobim 3y ago
> 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.
- janosdebugs 3y ago
  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.
  - carlosjobim 3y ago
    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.
    - janosdebugs 3y ago
      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.