But it's not obvious to me that approach was even a net win for Google as a business. Did Google Brain invent the technology that killed Google? TBD I think.
In the case of Google there’s a lot of internal reasons why they didn’t leverage this opportunity, but if they had done that they might have ended up making their main product even more sticky.
> "That did introduce tension for our team because we were supposed to be taking experimental bets for the platform’s future. These bets couldn’t be baked into product without hacks or shortcuts in the typical quarter as was the expectation."
If I can pump one learning into engineers' and PMs' heads it's this: intermediate deliverables are not optional no matter how cutting-edge your team is.
You will never succeed if your pitch to leadership is "give us a budget for the next N years and expect no shippable products until the end of N years". Even if you get approved somehow at the beginning, there's a 99.5% chance your team/project will be killed before you get to N years.
Again, once again for the audience in the back: there is no such thing as a multi-year project without convincing, meaningful intermediate deliverables.
To clarify, that doesn't mean "don't have multi-year roadmaps", it means "your multi-year roadmaps must deliver wins at a consistent cadence".
Understanding this will carry you a lot further in the industry.
As a fairly cutting-edge R&D team part of your job is to figure out what slice of this is shippable (and worth shipping). If you're coming up empty you are not ready to pitch this to execs.
If you look at all the defining products of Apple, they also took years from the “germ of an idea” until they could be launched, and though they might have “shipped” internally, they gained a lot by not having pressure to ship things piecemeal to customers.
A lot of community building comes down to trust, whether you are developing a commercial or open source platform. As a customer and integrator/consultant/developer, I want to know that the platform is going to be around and supported. The bigger my company the higher the risk is.
Open sourcing your software sends signals to your customers and partners. Some will see it as a last ditch effort to make it successful, with the flip side being that if it doesn't happen, you're won't be maintaining it anymore. Will that make them more or less likely to use your software/help build your community?
So in your messaging you should be very clear in what you want to achieve, and how you plan to build a successful business around an open source or open core model, and how the others companies fit into this. How will you respond if another company takes your code and does the exact same thing you're trying to monetize, only better? Etc.
You should also be careful about positive feedback. Most people like to be nice and supportive, and won't say negative things. The only way to know whether you'll have success there is to see actual commitment (in money or work spent) with your product.
Finally as others have said, you shouldn't expect automatic success/community by open sourcing the code. You might end up attracting the sort of customers / developers that have the least incentive to contribute or pay for additional services, unless you go find those yourself.
Arguably, what ultimately brought Palm down was their early success and the huge library of existing shareware and freeware tools:
They desperately needed to try something new (Palm OS was just showing its age as a single-threaded, in-RAM, non-virtual-memory-based OS), but couldn't, since it would have alienated long-time fans by stranding their existing software libraries.
They could never work their way through that chicken-and-egg problem (and all of the split ups (OS vs. hardware), forks/spin-offs (Handspring), and re-mergers didn't help either) until it was too late: Cobalt OS never saw any devices, and the Pre was an ambitious new start but would have had a tough time against the iPhone even if it would have launched earlier than that.
But as you say, the company structure, market position and a lot more worked against them (same thing with Nokia and Symbian).
The 13.5 sLaptop 6 for Business is, i5/8gb/256gb is $1200
Compare that the 14” MBP (M3/8gb/512gb) for $1600. The diff in SSD storage offsets some of the cost, but not the whole $400
However, the 13” MacBook Air with the same specs (although a much better CPU) - M3/8gb/256gb is actually $100 cheaper.
Until someone builds an actual M3 competitor, Apple’s making better laptops for cheaper.
I have an M1 16” MBP that’s still running laps around any other laptop I’ve ever owned, including the 15” sBook 2 with a 1060. The Windows Arm laptop I have sucks compared to the M-series.
Anyway, totally agree that Apple does the same cross-sell garbage as Microsoft, just think it’s way off to argue that their hardware is more expensive, at least meaningfully so when you compare the performance, longevity, and battery life.
None of the arguments against putting the processor in the battery make any sense. It adds latency? No it doesn't, if designed correctly, and I guarantee you can fit the correct design in the budget for $3500. You can't cool it from inside a pocket? The wire is sticking out already, you could add a short air intake to it. It would be too big? I guarantee that size is easier to carry in the battery than on your literal face!
The only thing that makes sense to me is the battery was supposed to be internal and the external battery was a last minute compromise for comfort. Unfortunately I suspect that Apple will go the direction of moving the battery back in for v2 rather than moving processing out.
Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point.
I just don't understand why you'd make that decision on a greenfield project today, especially if LSP support is planned at all?
Downsides: - if the software doesn’t get updated, you’re stuck running an old OS an old Mac that supports it. - you can’t just turn on the synth and use it, you need to find a cable, connect it to the Mac, launch the software, etc