Just because you want something to have a viable business model doesn't mean it does. If you want to get paid to develop open source software, I think you have a couple of options:
1. Just don't. Work on open source on the weekends, etc.
2. Do it as part of a "commoditize your complements" strategy.
3. Work at a company that is so large they can fund open source development as part of their advertising strategy.
4. Gather together some expertise in existing open source projects and sell consulting. Crucially, you'll probably need to build on top of some existing open source install base or name recognition. Redhat didn't start the linux project or the gnu userland, Percona didn't write mysql, etc. In some sense you are now one of the leaches that posts such as this one complain about.
The fundamental piece in common here is that the open source bit isn't the main value driver for the business.
I imagine that opinions such as this have influenced this recommendation: https://research.swtch.com/deps . I think there is some spirit in Go of not taking on a ton of small dependencies, but that may be a hold-over from before Go had a built-in package manager.
I think as an organization grows to some combination of available resources and severity of an outage this view becomes more and more common.
> There are a lot of organizations who want hyperscale style servers but aren't going to start a division to begin making them themselves.
How does this differ from what large players like Dell are offering under the "hyperconverged" moniker. For example, Dell's Vxrail[0] appears (from marketing speak, anyway) to be a single rack with integrated networking and storage that you can ask to "just start a vm".
Contra to most of the comments here, I found a lot to agree with in this article:
> You have no soul as a company at that point, you’re just trying to make money with other people, rather than help people with a problem that you know. You may think you have an idea, but it’s not good enough yet.
I think this is the crux of the difference. If you want to have a successful startup, you have to believe that you deserve to exist and believe you have something unique to offer. You cannot just "show up and listen" and get paid the big bucks.
One aspect of Lua that stands out to me is how every feature is carefully designed both in isolation and in composition with the others. The language has relatively few features, but none of them are hanging off the side, the all lean on each other to make a cohesive whole.
I think Lua is a bit unique in this for two reasons. First, they have in intentional open-source but not open development model. Second, because of the way that Lua is embedded inside other projects, there is more willingness to implement backwards-incompatable changes. I'm sure this is a negative for some who want to build a larger, less fractured community, but it has advantages for language cohesiveness.
> The coordinator communicates with each worker using an improvised JSON-based RPC protocol over a pair of pipes. The protocol is pretty basic because we didn't need anything sophisticated like gRPC, and we didn't want to introduce anything new into the standard library.
Interesting that this does not use `encoding/gob` by these criteria. I think `encoding/gob` is a nice example of what is possible with reflection, and I've certainly learned techniques from reading its implementation, but I haven't seen very many uses in the wild and this certainly would seem like a vote of no-confidence.
While this is true, in the context of alpine climbing where I first heard this statement, the bold alpinists who die young are very much not beginner-intermediates. I've interpreted this differently than just the "Bathtub Curve"[1] applied to dangerous pursuits.
Rather, there is a certain amount of objective risk in alpine environments, and the more time you put yourself in that environment, especially in locations you aren't familiar with, the greater the chance that something will eventually go wrong.
I'm always surprised by the number of famous alpinists who weren't killed on their progressive, headline-capturing attempts but rather on training attempts and lesser objectives.
I agree with many of the concerns the author raises, but I'm left with the question:
Given all this, what does layering give us?
It gives some deduplication, but only a crude form. It gives some reproducibility from building off a well-known base and tag, but not full reproducibility. It gives some security benefit from building off a well-known base, but not as large a benefit as standard package managers provide.
I would be excited to see a image distribution system based off of something like casync, maybe with an initial rootfs formed through image-focused distributions like yocto[1]. The embedded device ecosystem has been concerned with reproducibility, image signing, and incremental updates for awhile and I think their approaches are very applicable to container images.
I agree, and from the subordinate's point of view I feel having a regularly planned session lowers the barrier to raise issues early without making things confrontational.
Its the difference between "we talked about many things, including this issue" and "we need to meet to discuss this issue". I find the second starts everyone off on a defensive foot, regardless of peoples' best intentions.
As you said, the solution isn't the hard part. The reason that large companies aren't deploying their own solutions for this issue isn't that their engineers engineers that are incapable of developing their own solutions, but because then they would have to carry that patch forever, and if a problem was found with their particular solution they would be on the hook for it.
And yes, I do think this, "but everyone else is doing the same thing so it isn't really our fault" attitude is a problem.
So moral of the story: Making unreasonable demands and threatening to completely cut off funding for related projects works as a way to force a contractor to deliver despite "setbacks" on your end?
I believe these are the exact technical advancement the top-level poster was contrasting with cable networks, so the distinction matters here.