I see the misunderstanding. When I say "contribute code freely" I mean "without restriction."
You are certainly aware that the vast majority of code is under strict restrictions and will be leveraged for competitive/controlling purposes rather than being shared. Employees wishing to freely contribute code in these domains will have their requests denied.
We've both been employed by large SV companies; we both know how this works. The majority of software will be used in an attempt to control the market.
Vista and Windows 8 aren't the problem. Lack of presence on servers and mobile devices is the problem -- those are the two key spaces where OSS platforms have won out.
Linux is still not a significant player on desktops. Microsoft is still completely dominating that space.
Microsoft is opening their codebase because they've been crushed by the enormous efforts of open source. This concession was hard won over the course of decades.
Apple and Google do not contribute code freely, nor do they contribute a significant amount of their code. The contributions are limited to areas in which an advantage exists. One only has to look at the machinations present in other development platforms to realize the threat. Consider what's happened with Java in recent years. Or look to Swift. Or to the entire Microsoft ecosystem which was built in part on a foundation of open source. BSD licensed code permeates the Windows environment; to ask "what's the concern" belies a rather stunning ignorance of Microsoft's behavior over the three prior decades.
"with goals beyond pure financial gains and rock-bottom self-interest."
This doesn't paint an accurate picture. Google isn't deploying Fiber out of any notion of selflessness. This is a competitive play, and a very good one at that.
You say selfless ideals, I say this is exactly how "the market" and "competition" are commonly understood to function -- in the absence of corruption, regulatory capture and state granted monopolies.
"Sad that we still don't have any kind of common libraries or whatever"
We do have those. In this case the common library is called "libc." In this case (and in a few others) the Go team decided to intentionally avoid providing an interface to this function.
The good news is it would take just a few minutes to add support for go to call strftime directly from libc.
" A brand new Android flagship for the price of a months' rent. An utterly imaginably spectacular device."
But this isn't an utterly imaginably spectacular device. It's merely a run of the mill consumer-grade portable computer according to modern standards.
Your rent would be insignificant compared to, for example, the cost of a truly spectacular computer by modern standards, such as a modern search engine cluster with a price tag of perhaps a half billion dollars not counting ongoing opex.
That's not true. Working 40 hours in a week is not a problem. A contractor can put in an unlimited number of hours if they wish. 20, 40, 80 - it doesn't matter.
The differentiator you're probably thinking of is whether the worker chooses which hours they work. If the worker decides independently how much they will work and at what times then the IRS doesn't tend to consider the relationship employment -- regardless of how much time is put in. This is precisely how these driving services operate.
If the employer is scheduling a fixed schedule, say 9-5 M-F, then the IRS considers it an employment arrangement. Regardless of the number of hours worked. But that is not at all how these services operate.
Well I live a lot further away than Oakland. I commute from along the 680 corridor which is further than may are willing to endure, I think. Luckily there's still quite a lot of affordable housing in safe neighborhoods in San Leandro, Hayward and El Cerrito (to name a few), all of which are much shorter commutes than mine.
But the more general answer to your question: When supply outstrips demand the only reasonable response is to build more housing.
Complaining that driving jobs have low value isn't constructive. The value of those jobs will approach zero soon due to technology. Instead, address the economic imbalance and let supply meet the demand.
It's #1. Hiring is hard; everyone makes mistakes. Or sometimes people simply don't perform well in certain roles. Their deck goes into detail on this point IIRC. Try to fix it and if you fail, acknowledge the failure and move on.
Acknowledging that you will need to fire some portion of those you hire is an adult approach to the issue. Likewise from an employee's perspective. It's not a big deal to plan for things possibly not working out.
There were mentions of both technologies and I was replying to devindotcom who was talking about how high latency satellites are still useful. Here's a link to that comment: https://news.ycombinator.com/item?id=8920059
That is why I was careful to specify traditional satellite internet services. It appears the distinction was lost.
I think you might be confusing "fires low performers" with "fires people who have occasional misses." There's a world of difference between the two.
I have a few friends who I worked with at a large company, the kind with a large bureaucratic, broken management system that shuffles around incompetence without ever purging it. They went on to work at Netflix and they tell me how much they love it. They no longer have to deal with terminally incompetent divisions. They're top performers; there's no fear. If Netflix were stupid enough to fire them they'd instantly be buried in new opportunity. Of course, Netflix isn't that stupid.
Consider the economic incentives: A strong will-fire policy is a great negative incentive to prevent incompetent hires in the first place. It's not so scary if you're competent and capable -- and that's precisely the kind of people a company will want to hire..