Brilliant. Let unpaid volunteers fix and update the documentation for your proprietary systems so you don't have to pay someone to do it.
Can someone explain to me why people will inevitably put in countless hours of free labor for Amazon here?
Can someone explain to me why people will inevitably put in countless hours of free labor for Amazon here?
1) Special ad positions with front-page placement (currently #22 is "Willing (YC S15) Is Hiring a UI / UX Designer" https://willing.com/designer , a privileged post that can't be voted or commented on)
2) The moderators can and sometimes do intervene by removing certain comments that are critical of YC companies.
Comments make the forum more interesting to the community, which increases eyeballs and makes the front page spots more valuable. And shaping the discourse helps with damage control when necessary.
YC doesn't make money directly from the forum. But neither does AWS from their docs.
If you have a problem with a company making money directly from your content, why doesn't it bother you if they are gaining something else off you like influence? Do you think HN confers zero value to YC?
Engineers generally have a natural tendancy to fix things, and documentaitons are worth fixing. And it also helps their future work.
In general, I'm happy supporting a company that pushes the bounds rather than fretting over every little detail. If something doesn't work exactly as documented, I probably found a rather unique case. I'd rather struggle with the problem for an hour and suggest a fix, than have X, Y, or Z company pay someone to spend countless hours finding every possible edge case.
----
On top of that, there is a hugely beneficial conversation that often arises from the opening of issues. I've found that one of the best ways to engage in a meaningful discussion with a company is to open an issue on one of their code repos. Engineers are often more straight to the point than "marketing" or "business" types.
As long as this is in the spirit of collaboration and not a "source code dump" that a lot of commercially-backed projects do to earn an "open source" moniker ... I'm fine with it.
Having it on GitHub will also add additional context around changes in the form of PRs, Issues and the commit history.
As a Walmart customer it's in my best interest that the aisles are clean. But I will doubt the legality to ask customers to clean the aisles so they don't need to pay for a cleaning service. Actually using volunteers to replace employees is kind of illegal.
But regarding why people would bother helping. Well I guess it's the same reason some people help out with wikipedia. Not all of them do it for ideological reasons. Some are just very nitpicky and anal.
I'm a freelancer and when I am between client projects I try to just code without the internet for a few hours first thing in the day.
Foundations that own the open-source projects are allowed to use volunteer work by law. Corporations with a for-profit interest doesn't.
> or answering a stack overflow question?
This one is more tricky. But it depends on who asks the question? It is an individual to get help on a problem? Or is it part of the ways of working of a company to avoid hiring experts? Evaluating intention it's usually hard.
Sometimes it's nice to just make things better.
But if I spend a bunch of time fixing AWS docs, it's not like I have any need to fork it and use 8t as documentation for my own AWS-like service.
Intro-level documentation changes are the most common pull requests I get on any of my projects. And the people making them are not the ones being helped by intro-level docs.
It's a clear case of experts helping beginners.
also... with an OS project, I can actually get the code and see how it runs, test patches, etc. I can't actually do that with their services, and any docs I might contribute would be guesstimates as to how things actually work, vs how it actually does work (and what's intended), which would/should come from the company that actually owns the code in question.
Most people is good a heart and they want to help, even when it's bad for themselves or even illegal.
"Under the federal Fair Labor Standards Act (“FLSA”) and many state and local wage and hour laws, the use of volunteers and interns is strictly regulated." https://www.forbes.com/sites/richardtuschman/2012/08/24/usin...
Amazon strategy is just another example of "if it's online it's legal". Destroying jobs in exchange of "experience", "visibility" or "a better curriculum" is regulated and for good reasons.
Do they want their software to be free? That's good. Everybody can use it and anyone can collaborate. Do they want their documentation to be reviewed and expanded by voluteers? Why not hire Technical Writers?
https://en.wikipedia.org/wiki/Technical_writer
Amazon evades paying taxes while expecting that volunteers do their job instead of employees. The world economy can't continue running like this for long.
I've told vendors of documentation bugs - and they've even listened. I wasn't paid by the vendor, I was paid by my employer. Who has a business relationship with the vendor. I sort of doubt this is illegal.
I wish I knew. Reminds me of Google Map Maker, aka "Work for Google producing proprietary mapping data that even you can't get back for free".
At worst, it was a mix of old advice, bad advice, dangerous code snippets, and people treating it like Stack Overflow.
Usually the first N posts were some really shitty solutions and someone would have to scroll way down to see a reply that calls them out and offers a good solution. But someone browsing the docs are most likely to use the first solution that seems good enough, particularly beginners.
It's good to know there are bad practices out there, and the doc team should update the doc and show how to avoid bad practice.
I will happily take docs, such as rust's docs or NaCl's docs, which don't ever mention the possible of md5summing a password, to docs where there are hundreds of comments recommending exactly that terrible practice.
There are a practically infinite number of ways to do things wrong, and very few ways to do things right. Documenting the right way by exhaustively demonstrating the wrong ways is a fool's errand.
But more to the point, I will happily take no docs at all to docs that are more wrong than right.
Expecting a "doc team" for an open-source language to keep on top of what fresh hells people are doing with forever-deprecated things seems like a very big ask.
The payoff in this case is probably getting your name into the official docs and leveraging that reputation as an AWS guru into pay/promotions later
Another is to consider this as Amazon giving the users a standard, simple way of fixing the documentation issues they inevitably run into.
But in the case of documentation, by the time I figured things out and see that the documentation is wrong, I no longer need the docs and I know what to do.
I think that's a much better goal than helping Amazon make money.