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

The Few, the Tired, the Open Source Coders

wired.com

Post reply on HN
Print view View original

161–170 of 173 posts

Re: The Few, the Tired, the Open Source Coders

#161

Post by throwaway1723 »

gonational wrote: post #158
throwaway1723 wrote: post #128

Earlier quoted context omitted.

Well my friend, the soil where you're trying to plant your sensible words is just totally barren. Here on HN you'll most probably face feedback only from those who work exactly for somebody who's coming after some group as you say, or zealous dupes who follow the former for free. And that feedback will never be positive!

Well I at least found one sensible person! Thank you for your reply.

Fortunately yet sadly there are many more remaining silent or ignoring HN altogether... Thank you for commenting against the grain too!

Re: The Few, the Tired, the Open Source Coders

#162

Post by eesmith »

sokoloff wrote: post #111
eesmith wrote: post #80

Earlier quoted context omitted.

"passion" often seems like code for "will work more for free". From a business standpoint, it makes sense as it shifts risk to the potential employee. But like having unpaid interns, it biases the employment pool toward those who have extra money and time to work for no income.

I’ll be honest: I do appreciate devs who love programming so much they sometimes do it for free. I still pay them (inc interns), but everyone I’ve known who was great at programming did some amount of it for free somewhere along the way (because they can and they like it), whether it was open source, programming contests, or just checking out some new tech on their own and never shipping the code anywhere. Even thoug…

If you see that something did some programming for free, is it because they love programming? Or they love the increased chances of getting a job/money?

What do you think the ratio is? The recent Hacktoberfest/ pull-request/ T-shirt fiasco (see https://news.ycombinator.com/item?id=24658052 among many) shows that signal is definitely gameable.

Re: The Few, the Tired, the Open Source Coders

#163

Post by sokoloff »

eesmith wrote: post #162
sokoloff wrote: post #111

Earlier quoted context omitted.

I’ll be honest: I do appreciate devs who love programming so much they sometimes do it for free. I still pay them (inc interns), but everyone I’ve known who was great at programming did some amount of it for free somewhere along the way (because they can and they like it), whether it was open source, programming contests, or just checking out some new tech on their own and never shipping the code anywhere. Even thoug…

If you see that something did some programming for free, is it because they love programming? Or they love the increased chances of getting a job/money? What do you think the ratio is? The recent Hacktoberfest/ pull-request/ T-shirt fiasco (see https://news.ycombinator.com/item?id=24658052 among many) shows that signal is definitely gameable.

You might be worrying that I can't tell the difference between a gamed/BS pull request and a genuine side project.

If someone "games the system" well enough that they can cogently explain something interesting about their side project, do I really need to know if they grudgingly learned it because of money concerns or out of a love of solving puzzles with computers? By the time you can explain your side work and have some level of understanding/explanation that you can share, that's strongly positively correlated to me.

If you happen to be bad at programming and grudgingly trudged through it, that might show up once you're employed, in which case it was a false-positive. But it's at least a somewhat expensive false-positive for you to generate.

Re: The Few, the Tired, the Open Source Coders

#164

Post by dalke »

ThrowawayR2 wrote: post #153
dalke wrote: post #89

Earlier quoted context omitted.

I tried commercial FOSS development. An older version was available at no cost, the newest version cost money. Both were MIT licensed. If you were a company, and wanted to pay me, it was easy - send me a PO and you would get the source code to the newer, faster, more capable version. Nothing in that looks like a donation. I did it this way precisely because giving someone money for being "super nice" and distributing…

> " I came out of that workshop convinced that the primary reason companies like FOSS is because it's generally available at no cost. Not because it reduces long-term dependencies on external parties, not because it improves software development methodologies, and not because it's an essential liberty. But simply because of the cost. " This was, or at least should have been, known from the beginning; I've certainly b…

Yes, most FOSS business models of the 1990s were based on secondary effects. Like "people will pay you to add features / support the software / integrate your software in their system."

I deliberately did NOT use that model. Rather, you pay $$$ and get commercial software, which happens to be under a FOSS license.

In other words, I wanted to see what happens if it's not "free as in beer". If you are willing to pay for software, will you pay more, or less, for a FOSS license instead of a commercial one?

Turns out, people don't care - they want the cheapest one. At least, my customers' willingness to pay more for a FOSS license doesn't match my economic risk for selling under a FOSS license.

Re: The Few, the Tired, the Open Source Coders

#165

Post by dalke »

sokoloff wrote: post #107
dalke wrote: post #89

Earlier quoted context omitted.

I tried commercial FOSS development. An older version was available at no cost, the newest version cost money. Both were MIT licensed. If you were a company, and wanted to pay me, it was easy - send me a PO and you would get the source code to the newer, faster, more capable version. Nothing in that looks like a donation. I did it this way precisely because giving someone money for being "super nice" and distributing…

That cost is measured in dollars and in friction, not just dollars. There’s no software that I won’t pay $25 for if it helps my work. There’s some software that I’ll pay $100 for. It’s again difficult in the $100.01 to $1000 range and opens up again over that (only if the value is there of course). It’s fair to assume that slightly different purchasing approvals are needed in the buckets above. In all cases, I’m maki…

The software was in the $25K+ range. It's a rather different market, and different sales techniques -- made harder because my FOSS-only distribution model meant I couldn't distribute an evaluation version with more restrictive licensing.

The non-FOSS pricing is cheaper, but still in the $10K range. My last sale took about 15 months from start to finish.

FWIW, I got strong feedback that people wouldn't buy it with GPL licensing. It's library software designed to be embedded wherever you need it, so I can understand that.

Re: The Few, the Tired, the Open Source Coders

#166

Post by dalke »

andi999 wrote: post #106
dalke wrote: post #89

Earlier quoted context omitted.

I tried commercial FOSS development. An older version was available at no cost, the newest version cost money. Both were MIT licensed. If you were a company, and wanted to pay me, it was easy - send me a PO and you would get the source code to the newer, faster, more capable version. Nothing in that looks like a donation. I did it this way precisely because giving someone money for being "super nice" and distributing…

Getting a new supplier in our ERP system is a nightmare. Also for each order three quotations needed from different suppliers...

One of my customers' ERP system is a nightmare so they outsource many purchases to a reseller. I didn't understand what was going on when the reseller contacted me, and ended up being added as a supplier to my customer's ERP.

I then got paid twice. After 9 months and multiple inquiries I still don't know how to give them their money back!

Re: The Few, the Tired, the Open Source Coders

#167

Post by marcus_holmes »

themodelplumber wrote: post #160
marcus_holmes wrote: post #139

Earlier quoted context omitted.

Thanks for the info. I'm curious why there is a need for "professional" standards here? I feel that this is, by definition, not "professional" - that would require payment. Also, the imbalance of jerks behaving like jerks but everyone else has to act responsibly: in a work setting, sure - you don't get to choose your colleagues and you need to get along. But in this setting - why can't a maintainer just tell a jerk t…

I think that's an important ground rule, for sure: You don't _have_ to do any of that. You can absolutely tell a jerk to do whatever comes to mind. If you want. I know I've done that before. (I would add that I regretted it because, in part, it complicated community discussions later) In a lot of ways, I think that once you feel like you _have_ to do this or that, especially the professional stuff, your personal valu…

thanks, great advice :)

Re: The Few, the Tired, the Open Source Coders

#168

Post by eesmith »

sokoloff wrote: post #163
eesmith wrote: post #162

Earlier quoted context omitted.

If you see that something did some programming for free, is it because they love programming? Or they love the increased chances of getting a job/money? What do you think the ratio is? The recent Hacktoberfest/ pull-request/ T-shirt fiasco (see https://news.ycombinator.com/item?id=24658052 among many) shows that signal is definitely gameable.

You might be worrying that I can't tell the difference between a gamed/BS pull request and a genuine side project. If someone "games the system" well enough that they can cogently explain something interesting about their side project, do I really need to know if they grudgingly learned it because of money concerns or out of a love of solving puzzles with computers? By the time you can explain your side work and have…

Which sounds like your signal is "cogently explain something interesting about their side project" and not simply "did something worthwhile for free".

Re: The Few, the Tired, the Open Source Coders

#169

Post by sokoloff »

eesmith wrote: post #168
sokoloff wrote: post #163

Earlier quoted context omitted.

You might be worrying that I can't tell the difference between a gamed/BS pull request and a genuine side project. If someone "games the system" well enough that they can cogently explain something interesting about their side project, do I really need to know if they grudgingly learned it because of money concerns or out of a love of solving puzzles with computers? By the time you can explain your side work and have…

Which sounds like your signal is "cogently explain something interesting about their side project" and not simply "did something worthwhile for free".

Sure. I suppose that if you go deep enough, my signal is "will write good code here", which is suggested by "can write good code", which is suggested by "has written good code" and "wishes to write good code", which is suggested by..."did a side project" or "doesn't only write code when someone is standing there to pay them for it" or

Everything in an interview process is an approximation and guess.

Re: The Few, the Tired, the Open Source Coders

#170

Post by _greim_ »

rectang wrote: post #56
_greim_ wrote: post #43

Earlier quoted context omitted.

Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.

Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now . Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard . For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintain…

Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.
Post reply on HN