Live data from Hacker News

Give away your code, but never your time

wgross.net

201–210 of 228 posts

Re: Give away your code, but never your time

#201

Earlier quoted context omitted.

> everyone has a right to expect help and a right to give help This might make sense when asking a stranger for directions or for someone to help with your car problem, because the relationship is 1:1 . But this breaks down in contexts where scale is a factor. When assisting users of your project, the relationship is 1:many . And if the project is popular, it is unfair to expect the author to be helping so many peopl…

I don't really see how 1:to many makes any difference in principle. Perhaps you were thinking of the amount of effort to help the many? As in 1:1 case it is up to the helper to decide how many resources, if any, to spend on helping. A society where the default position is that people deserve help is different from one that is based on the survival of the fittest.

Even if the default position is to help, it can't be unconditional, there are limits. You don't have a right to expect help when it places an unreasonable burden on the helper.

Re: Give away your code, but never your time

#202
post #123

Earlier quoted context omitted.

Paying for PR? really? Why would anyone do that rather than maintain their own copy if it is an OSS project?

Maintaining your own fork means you are taking de-facto responsibility for the maintenance of more projects in addition to your paying projects. The costs of keeping them current adds up surprisingly quickly. In fact, it adds up so quickly that my company has a standing policy in place that we will do _whatever_it_takes_ to have any pull requests we need in an upstream project integrated in order to avoid us having t…

> I will _gladly_ pay the cost of 1 week of a senior engineer's salary to have you accept my pull request if you are prepared to either: > 1) do the quality control work yourself

I too would gladly pay one dollar for a hundred dollars bill.

Re: Give away your code, but never your time

#203
post #13

Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay. The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them. Most maintainers err on the side of controlling too much. Which makes them into bottlenecks. One or two good PRs is enough for me to g…

We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished. Sadly, lots and lots of little bugs and awk…

> main maintainer was getting tired

Would the project have had much development at all without the "helpful guy"? If the maintainer was too tired to even keep an eye on him/her, then it sounds like the project would have stalled without that help.

Re: Give away your code, but never your time

#204

Earlier quoted context omitted.

As soon as money is involved there is a certain expectation of quality and the work being done properly. If you start depending on that money then you are under the control of your customers and your hobby will quickly degrade into a regular job.

"Degrade"? Getting a job contributing to FOSS projects sounds pretty good to me.

Depends, turning a hobby into work can be either wonderful or horrible.

Re: Give away your code, but never your time

#205
post #123

Devil's advocate: How about an issue/PR tracker that lets users pay for priority? A simple bidding system. If BigCorp International is willing to pay $200/hour for IE10 support, they can be next on your list. And afterward, an bug with significant community support totalling $50/hour, pledged by 50 different users. With allowances for your own preferences as maintainer and the needs of the community, of course, but g…

Paying for PR? really? Why would anyone do that rather than maintain their own copy if it is an OSS project?

When you consider the cost of having to re-merge all your work on every update, I'd be more than happy to pay some reasonable sum to have it merged into master and maintained there. Could save me a lot of work.

Re: Give away your code, but never your time

#206
post #138

Earlier quoted context omitted.

That's a strange view of open source that borders on communism. You don't have any duties or obligation towards any individual to assist them with their issues. The only obligations you have is to be honest about the project. For example, if you know that the project is not written with security in mind, you must announce the fact, so that people don't go using the project assuming you took care of all potential expl…

I'd like to second this: > to be honest about the project Sometimes you see the attitude "You get what you pay for", but putting code in the ecosystem without property explaining what it is is like littering. In the same way I want to be able to walk in the park without constantly checking the ground for dog shit, I want to be able to use software without having to audit every part personally because the author didn'…

* I mean didn't care for security

edit: This down-voted too? The clarification?

Re: Give away your code, but never your time

#207
post #140
post #129

Earlier quoted context omitted.

In my experience, i donate to projects, which i use often/or build upon.

That's nice of you. Is it enough to keep the projects alive?

My data point would be Borg Backup, which, if you were to consider Bountysource to be payment for development, is under-financed by perhaps a factor of 40. 80+ % of funding came from three organizations.

And what I've heard from other maintainers is that Borg seems to do comparatively well.

So no, if you think in terms of payment, donations do not work in the open source ecosystem.

Re: Give away your code, but never your time

#208
post #134

Earlier quoted context omitted.

How often is commit bad enough to require revert, yet made it through testing and got released?

Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.

> Code style

How is that an issue in this day and age? Just run astyle or indent.

Re: Give away your code, but never your time

#209
post #162
post #134

Earlier quoted context omitted.

Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.

All those things should and hopefully would have been caught when the PR was made, not after the commits made it into master.

The entire context of this thread is that adding committers can introduce risk in the quality of accepted contributions. Building a trusted network of gatekeepers is hard.

Re: Give away your code, but never your time

#210

I think what open source needs is some very deliberate price discrimination. Have the license be free to the vast majority of users, and cost money for large corporations that can damn well afford it. Not, like, large amounts of money, just something vaguely close to the all-in cost of one full time developer. Basically, "BSD, unless you're a $1B+ valued company that is not paying our software foundation $10k/mo".

The problem with this is if you are anything more than a small company, it's pretty hard to get authorisation and approval to pay for software.

A couple of years ago I was working for a UN organisation, and to get approval to upgrade our plan of an alerting tool from something like $10/mo to $25/mo required many people involved and weeks of time (not weeks of people time, but weeks from 'we want this' to 'ok'). For something new we would have to evaluate it against other competing products, and then it's just a waste of everyone's time, instead of 'gem install sidekiq'.

Admittedly not every company/organisation is this extreme, but once you get to a certain size most companies have something like this.

(I felt we paid our dues to the open source community as we open sourced a lot of our own in house tools and helped maintain a lot of other projects we regularly used)

Post reply on HN