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

221–228 of 228 posts

Re: Give away your code, but never your time

#221

Post by zzzeek »

nextlevelwizard wrote: post #130
zzzeek wrote: post #107

Earlier quoted context omitted.

Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.

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

I'm talking here about a developer API that is extremely flexible and extensible. Even one-liner contributions can have bad effects, and virtually all contributions I receive "work" at a superficial level and if they provide tests the tests usually pass. "made it through testing" is a low bar, the bigger implications of a patch need to be considered.

Examples of PRs that "work" exactly as intended yet are the wrong way to solve the problem:

https://github.com/zzzeek/sqlalchemy/pull/381

https://github.com/zzzeek/sqlalchemy/pull/382

Here's a large PR:

https://github.com/zzzeek/sqlalchemy/pull/365

that after lots and lots of back and forth I finally merged with lots of edits from me at: https://github.com/zzzeek/sqlalchemy/commit/7d3da6f850dca54b...

...aannnnndddd - after all that work and testing, it was wrong! Fortunately someone caught the mistake within the beta release:

https://bitbucket.org/zzzeek/sqlalchemy/issues/4072/mysqldml...

if I had released that fully and the whole world coded to "mysql.insert.values.bar == 5", that's broken API since it breaks the values() method. Backwards-incompatible fix required.

Re: Give away your code, but never your time

#222

Post by rodorgas »

jasonkester wrote: post #157
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…

> creating an open source project is a contract with the community, and part of that contract is to assist members of this community I disagree. Creating an open source project is a gift to the community. Expecting further time and attention from somebody who gave you a gift, out of a sense of entitlement from having received the gift, is just being rude. Pay for my time and I'll help you with your issues. Demand my…

Whether you want give support and maintain the project or just throw the code, it's important to make it clear so people can have reasonable expectations. Also if you want provide paid support, make it clear too.

I've recently saw a license that make the author intentions of not giving support clear: DILLIGASPL (Do I Look Like I Give A Shit Public License)[1]. Sounds like a joke, but it's a way to show what are you up for.

https://github.com/samlev/DILLIGASPL

Re: Give away your code, but never your time

#223

Post by sverhagen »

sundvor wrote: post #99
sverhagen wrote: post #82

Earlier quoted context omitted.

Reading this makes me wonder, though... These maintainers are often well-paid professionals. If their lifes outside of their day jobs put the pressure to limit the open source work, what is a little money going to do? If money was their main motivator to compromise their personal life, would they not already have gotten a second job (like a part-time consulting gig), maybe instead of the whole open source thing? Make…

Not every developer is a highly paid superstar in Silicon Valley. When needing to juggle family / life, I'm sure this proposed model would make it a lot easier to explain to the wife/husband/partner why they need to stay up a bit longer at night to work on their (previously) non-paying projects.

I'm not saying that's what they are, but somehow I got the impression that maintainers of projects that are good enough to attract payments for pulls, would have marketable skills, and be ahead, regardless of the market they live in.

Re: Give away your code, but never your time

#224

Post by cdaven »

I just stumbled on a note from the abandoned project [History.js](https://github.com/browserstate/history.js/):

> Despite History.js being one of the most popular JavaScript libraries there is, and has been used by even multi-million-user companies in its time - the reality of economy and company practices seems to be that companies prefer to fork their own internal versions and fix locally with their own devs rather than fund open-source maintainers what they would pay their own devs to make things better for everyone, including themselves, which would be cheaper - but no, that would require too many tiers of company approval that don't understand the need.

> As such, if you are an open-source developer, I'd recommend just working on open-source projects that are paid for by your own consulting work or your own company (e.g. every successful open-source project). As otherwise, when they become popular, you better hope they are easily maintainable and testable, otherwise the cost of maintenance is higher than the free time of the maintainers.

Re: Give away your code, but never your time

#225

Post by ATsch »

hnlmorg wrote: post #191
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. 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.

Oh, great! I tried it a while ago and the setting was nowhere to be found!

Re: Give away your code, but never your time

#226

Post by quickthrower2 »

xfer wrote: post #125
quickthrower2 wrote: post #93

Earlier quoted context omitted.

Your employer benefits financially from the open source community. People who purchase software cheaply due to lower barrier to entry and more competition also benefit. As a coder I generally don't benefit so don't feel the need to give back. As a coder the tsunami of FOSS is a negative. My job is now to glue free modules together rather than design stuff. I'd be quite happy to pay for a compiler if I had to.

I mean if you are genius who has written all parts of OS/compiler/whatever software you use, then maybe it is a negative for you. But most people can't do so and FOSS is actually a blessing. If you like to pay for wall-gardens, where you can't read any code without an NDA/paying a million dollars, they exist. Feel free to use them.

I've been plenty happy working in Windows/.NET land. As a developer.

As a home tinkerer I do agree with you. And glad Haskell and Linux are available for free.

Re: Give away your code, but never your time

#228

Post by jancsika »

xfer wrote: post #128
sundvor wrote: post #99

Earlier quoted context omitted.

Not every developer is a highly paid superstar in Silicon Valley. When needing to juggle family / life, I'm sure this proposed model would make it a lot easier to explain to the wife/husband/partner why they need to stay up a bit longer at night to work on their (previously) non-paying projects.

You need to show income to justify your hobby?

As a potential contributor I need to know whether there's a professional process or a guy "playing with trains" on the other end of the wire.

The problem is that the FLOSS ecosystem doesn't give you an easy way to tell. So if I misjudge and hit a wall of dysfunction, the general response would be, "Well, the maintainer just wants to play with trains. Leave them alone and fork the project if you want it to be some other way."

At least with paying to contribute, it would force the FLOSS ecosystem general response to be, "Those maintainers are just playing with trains, but they're taking money as if they are professional engineers. That's bad." Of course that's worst case scenario-- best case is that they really are engineers and I'm funding their development. Either way, it's potentially better than the status quo which is that you have no idea until you submit the patch.

Post reply on HN