Open-source Community Rights: Should Bountysource allow committers to delist their projects? #930
Comments
|
As a maintainer: I want my community to come to an agreement on these things before money is introduced into the development cycle. It changes the way the project is maintained, and not always for the better. I personally have reservations against this sort of thing because I feel like it rewards people who do a little bit of work and let's those who do the vast majority (the original authors, the maintainers, those who have an ongoing, active role in the project) go unrewarded. This discourages the more important work of maintaining the project as a whole and ensuring all of these bountied bug submissions are integrated as a whole, while encouraging people to drop by and do the bare minimum for cash, which usually ends up with half-assed patches because they don't know the consequences of the systems they're integrating into. But regardless of what anyone's opinion is on the value of BountySource as a service overall, the fact remains that maintainers do the most work towards their projects. Maintainers have authority over what gets in and what doesn't. If a maintainer doesn't like BountySource, what's to stop them from rejecting patches they think come from bounties? Maintainers are the lifeblood of open source projects and giving them discresion in this matter is the right choice. Pissing off maintainers in the name of their communities is wrong. EDIT: Another concern of mine is that BountySource allows anyone to back any GitHub issue. Maybe I already have a person in mind for that issue or I already have a design in mind to solve it. Maybe it's a meta-issue. It's more complicated than just a list of things that need to happen to the code. |
|
As another maintainer, I don't know how to handle a bountied bug on one of my projects. Let's say someone opens a bounty, then someone else opens a pull request to fix it. For whatever reason I don't merge that pull request (maybe two people open pull reqs, maybe I don't like the solution and do it myself--or not--maybe I just don't think it's a good fit feature). Whatever the actual reason, it adds the tension of money into the community. While someone might be miffed that they spent time on a patch and it wasn't accepted, at least I didn't take money out of their pocket for it. For a developer--at least one who isn't the project maintainer--it means hoping to get paid for the work they do, at best, and feeling robbed at worst. This isn't entirely academic: I routinely take branches from pull reqs and do clean-up on them before merging by hand. Who earns the bounty then? Am I supposed to somehow notify you of the specific commit or committer that fixed it? There are a lot of questions here. If a company is paying someone to work on a feature, it's work for hire, so does the company have a right to the bounty if it gets merged? If I don't merge something and someone forks the project and merges it in the fork, then what? I really appreciate that you're having this discussion. I think experimentation in open source like this is important. But there are a lot of open questions that I can't really answer, and don't have time to. And, these aren't problems I opted into: they're problems I can't opt out of, unless I stop maintaining code on GitHub. I don't really want to dive into different solutions to bounties as a whole, but I would really appreciate the ability to at the very least opt-out my repositories. Really, I should have had to opt-in in the first place. |
|
@SirCmpwn and @jsocol, thank you both for your feedback. I've tried my best to respond to your points below. SirCmpwn:
In our experience this isn't the case -- It's been core contributors who earn a significant portion of the bounties. And while many of the responsibilities of the core contributors may go unrewarded, that's no reason to block rewards from others in the community. Instead, let's find ways to better support and reward core team members. Donations to teams are popular on Bountysource, and these come with no expectations from the donor. We're also planning features in the future to better support teams, such as recurring donations. Another thought, what if the project collected a "tax" on all earned bounties that went to the core team?
Agree 100%. Code that doesn't meet the standards of the project maintainers should absolutely be rejected, regardless of whether there's a bounty or not. If low quality submissions become a problem, we'll quickly implement a peer-review system that requires developers to have somebody else +1 their code before their pull request will count towards the bounty.
This seems like an extreme stance to take. What if you misjudge and assume a PR was because of a bounty, but wasn't? What if a long-time contributor (who knows the ins and outs of the project) works on an issue because of a bounty? Accepting or rejecting contributions should be based on merit.
If a GitHub issue is open, the implication is that it is a valid issue that needs to be solved. If an issue is invalid or no longer relevant, simply close the issue on GitHub as usual. Any bounties on an invalid issue will be refunded.
If you have a person or design in mind and somebody else comes along and submits a functional and well written pull request, that's a good thing, right?
Rarely do issues list out precisely what needs to happen, so there's always a sense of discovery. If there are dependencies on other issues or larger problems that need to be solved, that's the nature of software development. As long as the issue remains open, the bounty will as well. If multiple developers are involved in a solution, the bounty can always be split. jsocol:
Bounties should always be treated as rewards, and never as guarantees. If we were to establish one-to-one contract relationship between developers and backers, it would be different. Yes, developers are hoping to earn the bounty, but they go in knowing all of the variables around open-source.
This is common behavior. If the other developer submits a bounty claim and you do not, they will be awarded the entire bounty. If the clean-up is a major undertaking, you can also submit a claim and we will split the bounty between both you and the developer (currently a manual process that we review case-by-case). There are definitely other ways to reward maintainers, and I'd love to embrace them without cutting bounties out. The previously mentioned donations and "project tax" are two ways we can accomplish this. There could also be bounties for code reviews, or set percentage of a bounty that goes to the person who polished off the PR from another person.
This case has come up and, yes, the company has claimed the bounty on behalf of the company's development team. This $2000 bounty on SASS is a good example.
The bounty is placed on the open issue within your project. If your issue remains open, the bounties can't be claimed. |
You don't understand. If I have a design in mind, it's because I can foresee how it'll integrate with the system as a whole and I know the broader implications. Every single one of my projects encourages discussion before anyone picks something up for that reason. If I have a person in mind, it's because that person has the same knowledge that I have on the matter. Someone who finds issues through BountySource is likely to waste their time on a pull request that can't be merged for this reason. That might not be the case in projects where the issues are documented well enough to allow entirely independent development, but that's not the case on my projects, and I don't want it to be. I want the people helping with my software to form a community of people who can share ideas and work together for a better whole, so it's entirely intentional. It's my choice if that's how I want to run my projects, and it should be my choice if my projects will be run with the desire for money.
Keeping around older issues just tends to happen. Sometimes a problem gets fixed and no one goes back to close the issue, or sometimes no one notices a duplicate, or sometimes the issue becomes irrelevant. I volunteer my time for my projects and if I don't spend the time grooming my issues, that's my problem - but also my choice. Do not blackmail me into a certain style of issue management. As an example, I just went to my biggest project (1,324 stars) and looked for some issues that are no longer relevant: 635, 608, 579, and 572 are all invalid just on the first page. Without a person who dedicates themselves to grooming the issue trackers on my projects, they aren't always accurate. The correct way to contribute to my projects is to approach us through whatever means we've provided (typically IRC) to discuss what you'd like to help with, so we can guide you and help make sure your contribution is up to snuff. A third-party getting in the middle of this only makes it worse.
You can say that, and I agree, but there are extreme people out there. Other projects are not likely to be as reasonable. Money is a passionate issue to some people. If you don't cooperate with maintainers, they won't cooperate with you. In response to your entire comment, you took my intent to mean that I am jealous of the drive-by contributors for receiving money for their work. I didn't say that maintainers aren't rewarded because I wanted a reward, but because I would refuse one. I do open-source work for the benefit of humanity, not myself. Incorrectly distributing the wealth is not a solvable problem - the correct distribution doesn't want it. The only way that I would personally do open source for cash is for a consistent salary - and I do, sometimes. Rewarding based on patches is not a sustainable way to make a living, and I don't want the tax complications of trying to figure out two income sources, including one that I have to do considerably more work to file when considering that it's more or less self employment. I also don't want to concern myself with any problems that may arise from having contributors earn money from submitting code to my codebase, either. The entire codebase is under one license with my copyright statement on it, in most cases. What legal situation would that put me in if money was introduced? I don't want to know. I think the clear answer to these questions is that the maintainers have authority over their projects, and it's clearly morally wrong for you to disregard them. After I have put in years of work and thousands of lines of code, who are you to offer money to people for contributing to my codebases? That decision falls to me and me alone. On a side note, the repositories I asked you to remove are still there. Don't you think it'd be a sign of good faith to remove them until this discussion is resolved? |
Let them find their way, then! You say this is incredibly complicated but it is not complicated. Just delist people who ask, because you are providing them with negative utility. You think you know what "the people" want, well here they are telling you what they want. How about listening. |
The catch is, "finding a way" will look a lot like cloning Bountysource. If these systems are going to exist, then the best we can hope for is a responsible party administering them. At least by having this discussion, Bountysource is trying to thoughtfully engage with the rest of the community. |
|
I read your response and a couple of things struck me:
(my emphasis) There was a quixotic tone throughout your response. Yes, all of those those things should be true, but you're introducing money into it. Money has a way of changing these things from quixotic to messy. Consider the classic Ultimatum Game. Should I choose a small bounty over nothing? Should I consider a bounty a bonus or "gift" for something I would've done anyway? Rationally, of course I should. But humans don't work that way. You answered a couple of my concrete concerns while seeming to miss the bigger theme: there is a lot going on here—lots of questions, concerns, issues that haven't been resolved yet—and right now the only way for me as a maintainer to avoid it is to remove the code and issues from GitHub. That's not OK. (If someone has data showing an improvement in meaningful metrics because of bounties—or even correlated with bounties—I'd love to see it.) Would you, at the very least, consider an opt-out mechanism, if not making it opt-in? |
"YES." |
|
FYI, there is also discussion about this issue on Hacker News. |
|
Thank you all for the conversation, the feedback is definitely appreciated. We've decided that we will allow any project owner to disable bounties. Public data from GitHub will still be synced as usual, but bounties will be disabled for those projects. As of now, this is handled as a support task. Anyone who wishes to disable bounties should contact support@bountysource.com and we'll take care of it. |
|
As a part of the community, I think that delisting is against my rights. (Example. A project is published under a libre license. We have the right to change the source code, to become developers ourselves, or to hire another developer. Bountysource is just supporting this right. Delisting means that the developer allows
This sounds like a weird restriction, like that the developer is trying to forbid us to use money/Bountysource.) For example, what should we do if a developer refuses to work on his or her project and delists it? |
Recently, the question has come up regarding what we should do when an open-source project does not want to allow community members to post bounties on their issues. This is, no doubt, in direct response to the recent discussion on Hacker News about tip4commit.
We do our best to accommodate any request, so the initial thought was to remove the projects from our website as requested. This would be the quickest and easiest resolution. However, this immediately led to an internal debate regarding a community’s rights, and we’re now looking for more input.
Bountysource’s goals.
We built Bountysource to give more people the ability to improve open-source software. There’s a direct need we’re addressing by providing open-source developers new ways to be self-sustaining. Typically, development sponsorship comes from full-time employment at tech companies, one-off contract work, or “donated” time as a hobby. Additionally, we’re giving an outlet to those who otherwise would not contribute.
We consolidate data around open projects into one organized place. Currently, we sync issues from any public repository we support (GitHub, Jira, Trac, Bugzilla, Google Code, Pivotal, and Launchpad), with the aim being to support all open-source projects.
The challenges of removing a project.
Removing a project on Bountysource is incredibly complicated, and not in a technical sense.
For every bounty, there are multiple parties involved and each has different concerns.
Project owners: Project owners work extremely hard to manage all aspects of their project (branding, code quality, support, legal, etc) and are expected to establish the culture of their community. Some projects fear the introduction of money will transform the community in ways they do not want.
Developers earning a bounty: Developers can already submit code to projects, regardless of their motivation. The code itself must stand up to the quality requirements set by the project owners. It shouldn’t matter if the accepted code happens to satisfy the need of others who are willing to pay.
Backers creating a bounty: Backers rely on Bountysource to have a comprehensive listing of open-source projects and, if we don’t, ask us to add their favorite project. Bounties provide a way for more users (both technical and non-technical) to contribute to projects.
Bounties don’t need the core team to be effective.
While many bounties are earned by the core project team, that’s not a requirement. The project should review all code submissions based on quality alone. It doesn’t matter if the motivation for the code was because the developer needed to do the work anyway, was bored on a rainy day, is paid full time by Google, or did it because of a community-driven bounty.
What happens if we remove projects?
Delisting a project on Bountysource does not prevent users from offering bounties through forums posts, Twitter, and GitHub comments -- but it does remove a proven community tool. If the people want it, they will find a way.
What happens if we don’t remove projects?
If we refuse to remove projects, we stand to upset any developer that requests their project be removed. We love open-source -- we don’t want there to be animosity directed at us.
What do you think?
The text was updated successfully, but these errors were encountered: