6 ms·
Vendor lock-in will always inevitably backfire, because developers and users don't want to be trapped. It might work to maximize profits in the short to medium
by snek_case 5y ago
Vendor lock-in will always inevitably backfire, because developers and users don't want to be trapped. It might work to maximize profits in the short to medium term, but there's very strong financial incentives not to be stuck with a single platform. Vendor lock-in could mean the death of your product, or even your whole business.
- infogulch 5y agoMost new products are positioned to grow into a form of locked-in market that you can extract value from, drawing a box around their customers for the sole purpose of squeezing it in the future. This business strategy is a mind virus and has even overtaken the aspirations of bright-eyed entrepreneurs. The aim has fallen from the simple "get rich by selling a $1 item to 10 million people" down to "create a product where customers are trapped in a dependency relationship with the product by design, give it away below cost to push out alternatives, then flip it and squeeze them for as much as possible" (where the last part is omitted from the initial business plan but still implied, and enabled by outsourcing the dirty work to new management via buyout). The primary goal should be to maximize value, and within that a balanced tension between maximizing delivered value vs maximizing captured value. It's reasonable to be compensated for the value you add, but it needs to be in service of maximizing value in general. If the correct hierarchy of goals is inverted and capturing value becomes the primary aim then it inevitably devolves into this antisocial, monopolistic, lock-in behavior.
- Grustaf 5y agoI'd say at least 95% of Swift users don't mind at all that it's mostly an Apple language.
- samhw 5y agoWell, and 95% of heroin users don't mind needles and constipation. It's trivially true that the people who end up using a product are mostly the people who are content with its tradeoffs. That doesn't say much at all about whether those tradeoffs are ultimately optimal.
- Grustaf 5y agoI don't know about optimal, but I've been a Swift developer since day 1 and yet never heard anyone I know complain about Swift being to Apple centric. It's typically armchair philosophers online that have purity concerns, not practical developers.
- b3morales 5y agoI don't have a problem with it being Apple controlled. I have a problem with it being presented as an open project while simultaneously Apple completely controls its trajectory and maintains private forks of everything, which are where the developer tools are actually built from. If it was a closed process where neat stuff just dropped out of the sky each year, that would be fine. When features drop out of nowhere each year and then get laundered through ex post facto public "review", then I take issue. If it was a closed process then we would expect that only features coming from Apple would exist. In a truly open process there would be facilitation for contributions from people outside the organization. In the Swift project as it is currently run, those contributions have withered on the vine; the core team doesn't particularly welcome or support anything that didn't originate internally.
- Grustaf 5y agoThis is a textbook example of what I meant by philosophers obsessed with purity. And it doesn't sound like you're actually following Swift Evolution. A) Most of what happens is done in public, only rarely do they hide stuff until the last minute, like result builders for SwiftUI. B) As far as I know, they have never claimed that it's going to be completely open and 100% community controlled. The core team is mostly Apple employees, that is not a secret.
- deleted 5y ago[deleted]
- b3morales 5y ago> it doesn't sound like you're actually following Swift Evolution Nope, you're completely wrong about that.