This debate is not new.
If you built applications for IBM VM/CMS or GECOS systems, you used proprietary APIs. If you built for VMS, DG/UX or HP-UX, you used proprietary APIs. Same for applications built for Windows or OS X.
Yes, open protocols and APIs and standards are preferable and "open" is great. In theory. In practice, things always get messy. "Open" doesn't solve many of the problems that the customers (the folks with the money) have.
Linux - while not proprietary - has its own hassles with application portability. Try deploying with GNU autoconf/configure anywhere other than a GNU/bash system, for instance. Linux is inherently very open, but can also be surprisingly constrained.
For larger and more complex and longer-lived applications, the only viable long-term approach I can see involves a mix of open (eg: writing most of the code in portable C, Python or Lua or...) where that's possible (such as in the application kernel), and then using vendor interfaces where it's not.
Certainly presenting web interfaces or connecting to Twitter where that's appropriate.
For the smaller and "throw-away" applications, or when specific customer requirements such as gonzo-level I/O or graphics performance is needed (to have a product that's viable for, you know, your customers), then you're using the vendor APIs; you're writing non-portable code. The whole discussion of "open" is moot for these applications. (And I've seen many 4GL application generators come and go, too; you can be portable and chained to one vendor, at the same time.)
Application portability and controlling your stack is a very old topic of debate. And it's one filled with trade-offs. Of the trade-offs that a commercial developer makes involves determining what customers will pay for. And with most customers, "open" just isn't a priority.
This is a very old discussion and debate. Look at your history. And more importantly, look at your customers needs and expectations.