Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Give away your code, but never your time

wgross.net

Post reply on HN
Print view View original

191–200 of 228 posts

Re: Give away your code, but never your time

#191

Post by hnlmorg »

ATsch wrote: post #169
ef4 wrote: 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…

A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master

You can do this on Github. It's even called the same. Go to your repo -> settings -> branches and it's the 2nd item (Protected branched).

I use this feature at work so I can confirm it behaves as expected.

Re: Give away your code, but never your time

#192

Post by cavneb »

mjibson wrote: post #97
cavneb wrote: post #72

As much as I agree with the sentiment behind this post, I disagree with the implementation. The nature of open source code is collaboration. Paying for collaboration seems like it would hinder progress altogether and possibly direct the project into a direction that is not suitable for the poor majority not paying. One more thing that bothers me is that money for maintenance should not come from developers. This is l…

I've seen these kinds of things and have always been dubious that they are able to pay a full time salary for someone that is even close to what they could make with a normal full time dev job. What's the highest monthly amount your company pays a dev? What's the average and median?

Most of those using Code Sponsor are very new. I can tell you that so far this month (Sept 11) we are payout out $511 USD to developers. Last month we paid one developer over $130. It's not life changing, but it's excellent supplemental income.

Re: Give away your code, but never your time

#193

Post by cavneb »

quickben wrote: post #120
falcor84 wrote: post #111

Earlier quoted context omitted.

>They have a special section in their ToS that prohibits advertising Ehm, your quote does not quite support your statement: >We do not generally prohibit use of GitHub for advertising

It's a TOS, worded for PR, besides which it's unenforceable and at the whim of GitHub. It's like building a business on Google Reader or FB Parse.

We have advocates at GitHub and are in discussions with their compliance team. Code Sponsor is not directly tied to GitHub for it to be successful. Many of our developers are making money through different channels such as npm or their own generated documentation website.

Re: Give away your code, but never your time

#194

Post by rootlocus »

CM30 wrote: post #165
doozy wrote: post #85

Earlier quoted context omitted.

Many moons ago I developed a moderately successful shareware program. My licensing terms were simple: If you owned the computer where you installed and used it no license was needed, but if someone else owned the machine, you owed me money. It allowed students, hobbyists and freelancers to use the software for free, for any purpose, but companies, institutions and governments had to pay to play. This idea does not se…

Interesting idea, but two things struck me here: 1. Does that mean a student would have to pay to install it on their school computer? Or maybe a school provided laptop? 2. What about personal installs for other people? Not as a business or service, but merely on a friend or relative's computer? Because in theory, both of those would come under 'someone else owning the machine', but they'd also be seen as personal us…

I agree with the first, but the second doesn't qualify. If the person using the software (a friend) owns the computer where the software is installed (my friend's computer) he qualifies for the free license. I don't think it matters who actually did the installation.

Re: Give away your code, but never your time

#195

Post by hnlmorg »

lamby wrote: post #180
ATsch wrote: post #169

Earlier quoted context omitted.

A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master

You can do this on Github with custom hooks etc. But yes.

That's potentially one way of doing it but Github does also have a specific feature for doing this literally called "Protected branches":

https://github.com/blog/2051-protected-branches-and-required...

Re: Give away your code, but never your time

#196

Post by cavneb »

vjeux wrote: post #109
cavneb wrote: post #72

As much as I agree with the sentiment behind this post, I disagree with the implementation. The nature of open source code is collaboration. Paying for collaboration seems like it would hinder progress altogether and possibly direct the project into a direction that is not suitable for the poor majority not paying. One more thing that bothers me is that money for maintenance should not come from developers. This is l…

You're likely going to be shut down by GitHub. They have a special section in their ToS that prohibits advertising. https://help.github.com/articles/github-terms-of-service/#k-... > Short version: We do not generally prohibit use of GitHub for advertising. However, we expect our users to follow certain limitations, so GitHub does not become a spam haven. No one wants that.

Even though GitHub may say we cannot do this on their website, it does not prevent developers from generate a healthy side income building OSS.

Here's a blog post we just released which includes links to different developer repos and sites (aside from GitHub) https://medium.com/@codesponsor/fighting-for-open-source-sus...

Re: Give away your code, but never your time

#197

Post by ngo123 »

ef4 wrote: 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…

> Most maintainers err on the side of controlling too much.

Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.

Re: Give away your code, but never your time

#198

Post by chc »

sorokod wrote: post #188
icebraining wrote: post #170

Earlier quoted context omitted.

I upvoted you because I think it's an interesting position, but you should realize that adding duties will discourage people from doing any contributions at all. It starts to feel like a case of "no good deed going unpunished".

I wasn't thinking of legal rights and obligations but rather of a moral ethos. The alternative brought to it's logical conclusion is Shkreli and rasing medicine prices by thousand percent.

The alternative to giving away your personal time for free to an open-source project is gouging people on vital medication? That doesn't seem true in any sense.

Re: Give away your code, but never your time

#199

Post by jordigh »

ef4 wrote: 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 awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code.

I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.

Re: Give away your code, but never your time

#200

Post by retSava »

hasenj wrote: post #138
LeoNatan25 wrote: post #8

> We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer. > The message to users should be “do whatever you want with the code, but pay us for our time if you want to influence the project’s future.” So, for me, this goes against the reasons I decide to give my personal time to the community. For me, creating an open source proj…

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 really like and appreciate the notion that a project could/should state what the assumptions are, where applicable. And, perhaps point out weak spots that could be important to users. If nothing else, it sets the expectations right.

The perfect example is yours, "this project does not take security into consideration. Use at your own responsibility. You should probably start with securing this_X, that_Y, and that_Z.".

Another example could be "this is a POC and does not go kindly on system resources. You might want to scale back the number of simultaneously opened sockets for any real use."

Post reply on HN