Glad you like the Student Developer Pack. All credit goes to the 100+ partners who provide something like $200k in tools and services to each student who qualifies for the pack. It's kind of mind-boggling, actually.
As for how we sustain ourselves -- lots of big enterprise customers!
Good point. For anyone using the Student Developer Pack (or any other similar student offer), ask yourself this: Do you really want to become reliant on software and services that will cost you ~$70k/year as soon as you graduate?
Well, unless they decide to switch market or shut down, in which case you're hosed no matter how much you're willing to pay.
You can see that there's a lot of overlap and that these offers cover very broad sections of the industry. This gives students the opportunity to explore and develop immediately employable skillsets without impacting their already limited budgets.
And you only use a subset. And your employer is typically very happy to pay money for productivity.
For sure this is to the benefit of the involved companies. But paying for good tooling is normal not strange. When you go to your local handyman he will tell you a lot about good and expensive tools.
> And your employer is typically very happy to pay money for productivity.
And that's money that's not going to better equipment. Or your salary. Or whatever else that it could be spent on that would have a far bigger effect.
> But paying for good tooling is normal not strange.
Paying for bad tooling is normal. Good tooling tends to come as a consequence of trying to solve something else.
Bad tooling also tends to be much more expensive to produce, because it's so prone to scope creep. Visual Studio had to build their own Docker wrapper, because telling people to just use it directly would give their users a glimpse of the outside world, and we can't have that!
> When you go to your local handyman he will tell you a lot about good and expensive tools.
The vital difference is that physical tools are expensive to duplicate and maintain. You can't distribute a hammer via BitTorrent.
> Visual Studio had to build their own Docker wrapper, because telling people to just use it directly would give their users a glimpse of the outside world, and we can't have that!
Do you actually believe this was the reason behind developing Docker wrapper for VS? I mean you can always try stretching out the worst intention and motives, but do you actually believe this?
Suppose you do, how do you think about the gazillion 3rd party open source extensions to VS code? Did Red Hat develop OpenShift extension because they are part of the conspiracy too? Do you think that this is part of course change due to the IBM acquisition?
>The vital difference is that physical tools are expensive to duplicate and maintain. You can't distribute a hammer via BitTorrent.
The fact that you can distribute software for nearly free doesn't make the cost of producing it to be cheaper than hammer.
> Do you actually believe this was the reason behind developing Docker wrapper for VS? I mean you can always try stretching out the worst intention and motives, but do you actually believe this?
I don't think there is an explicit conspiracy. I do think there is a negative spiral where IDE addicts (for the lack of a better term) produce tools that "help" others avoid leaving their comfort zone.
I'm not immune to it either. When trying to learn Kubernetes I spent weeks fighting the graphical dashboard before just hunkering down and learning the core concepts and building my own intuition.
And I still like having an integrated environment. But with Emacs I'm at least generally just a `describe-function` or `describe-key` away from peeking behind the curtains.
> The fact that you can distribute software for nearly free doesn't make the cost of producing it to be cheaper than hammer.
Bad analogy. Producing it would be closer to developing the blueprint. Which is:
1. Done once
2. Tends to happen without economic incentives because, as it turns out, you probably want a hammer too
> I do think there is a negative spiral where IDE addicts (for the lack of a better term) produce tools that "help" others avoid leaving their comfort zone.
Alternatively, many people see value in focusing on what they develop and not have to bother studying the fine details of the underlying platforms they use. As someone who live deep down in detail and assist others using tools in the whole range from IDEs to cli, I have no disrespect for engineers who won't bother spending their time on knowing the subtitlities of the systems where their code will run.
>Bad analogy. Producing it would be closer to developing the blueprint.
Software tools are far from blueprints that are done once, they require constant maintenance to be compatible with changes in other tools and environments, bug and security fixing as well as implementing new features that users request.
Software development is extremely expensive, libre software is free only because someone is paying the cost of production and prefer to distribute it for free. Probably most of the open source software today is paid for by big companies, and their aim is usually to gain something from the investment. Docker wasn't developed as a manifestation of free speech, nor was Kubernetes born under GNU's roof. If not for the piles of money Google and Red Hat spent on it, Kubernetes couldn't be anything resembling the amazing beast that it is.
> Docker wasn't developed as a manifestation of free speech
Docker was developed because a cloud provider (Dotcloud) wanted a better way to package their own and their customers' software. As it turned out, Docker was succesful while Dotcloud failed spectacularly. So Docker became the main product.. and now that failed too, as of a few months ago.
In short, Docker's development was payed for by a company for commercial purposes. Moreover, it was build as an abstraction over kernel features so that developers won't need learn anything about them. It's success is product of the fact that tools can create extremely useful abstractions and when they do people benefit from using them and depends on them.
As for how we sustain ourselves -- lots of big enterprise customers!