This was Bezos' reasoning for making as much of their internal software available to the public via AWS, a) now it's required to be documented, b) it's now subject to competition, you know it's not the best if no one's using it.
https://www.networkworld.com/article/2891297/the-myth-about-...
GP was talking how this improves reward structure, not about AWS
[1] https://medium.com/slingr/what-year-did-bezos-issue-the-api-...
This was Bezos' reasoning for making as much of their internal software available to the public via AWS
Those APIs had nothing to do with AWS. So how was the original poster not talking about AWS when they mentioned AWS?
Also a clean public interface says nothing about how badly written and documented the underlying code is.
The mandate was in 2001. AWS first launched in 2006. From reading the letter, it wasn’t about being able to make services productizable. It was more so teams could work independently and choose whichever underlying technology they wanted. It also prevents the issue the original poster was having. It’s much easier to make changes to a small API than a monolith.
It takes a lot to go from internal API to product even on a small scale. Werner Vogels said at the last Reinvent that S3 is made you of hundred or more separate internal services exposed internally via an API. My last company we also had a mandate to be “API first”. Not because we were trying to be like Amazon with less than 75 people, but we actually sold access to our APIs to our customers - large business that used them as the backend for their websites and mobile apps. We also used the APIs internally for our websites and large ETL jobs where sour clients would send us files for bulk changes.
I doubt proprietary tech is going to fade completely, but it's true that maybe there are forces that are pushing for big companies to make more and more projects open source. If you think about it it makes sense: the employees are happier because their work has more impact, they also benefit because they can showcase it in their CV. For the company they externalize testing, quality improves because employees are going to be more careful when their code is in the open and they are more motivated. It can also make hiring easier.
This idea will never become a reality for the vast majority of companies, for the exact same reason that companies fear piracy. If I open source my product then anyone who uses that open source code is a lost sale. A lost sale means I make less money, less money means the board is mad, on and on and on...
The bottom line is money, and open sourcing their code means (to them) a loss in potential revenue.
I predict the open source bits will be bait. With many 90% solutions. The proprietary bits will be the ones you need to make it work like a real program. Oh there will still be soup to nuts full on free stacks. But I seeing more and more of this service fee way.
As for making hiring easier? Not so much. When you can get 100+ applicants for 1 position. The reality is at least 99 of those have to go away. One more filter does not do much other than let you round bin things faster say 'cant find anyone' then grab your favorite contracting firm and hire them anyway.
But I went from needing technical support from elastic 4-5 times a year, to zero and found work arounds for the other limitations, like cognito for authorization and storing less data in the cluster. The end result was a six-figure savings on licensing and less weekend work for me at the cost of a five-figure increase in AWS costs.
I'd say it was worth it.