I’ve been thinking this over a little bit. From a “business” perspective, the core of FW is sustainability. What it seems you’re suggesting is more along the lines of product diversity.
…
On the technical side, modularity seems like it fills both of these requirements.
@Kimberlee_Model I agree that sustainability is the primary purpose. For the product diversity, I think it’s important to distinguish the sustainability of the FW laptop itself supported by FW, with the product diversity with less sustainability not supported by FW in the area including the FW ecosystem. Thriving ecosystem is also important from a business perspective to make the FW as a platform attractive.
In the case of a gaming machine like XBox, PlayStation or Nintendo device as a platform, the value of the gaming device depends on the games that work on the device.
Thinking about sustainability, I’m not sure that filling niche requests is the right way to go about this. (Not to say I don’t want niche products myself), niche items tend to be harder to produce. I think they’ll probably aim more towards the middle of the market with somewhat more mainstream products.
The 2nd case is the Red Hat Enterprise Linux. The Red Hat supports the Linux kernel and their shipped RPM packages. But the company doesn’t support the 3rd party’s or someone’s open source software on the OS. The 3rd party’s softwre contributes to the ecosystem’s diversity. And an attractive open source software (OSS) survives with sustainability, but some OSS doesn’t. That’s natural.
I think that FW should not support the 3rd party or individual’s product itself. Instead, FW should invest in an environment where 3rd party or individual’s products will thrive. That’s about the standard interface, providing documents, creating a marketplace for monetization, and etc.
The 3rd case is CI (Continuous Integration) service, Travis vs GitHub Actions. I am not sure if you are familiar with this topic. But there is a very good case about what the platform should support.
- Travis has the programming language specific feature in their config file. For example in Ruby, here is the Ruby language feature supported by Travis. Travis is supporting the diverse programming languages feature by only themselves. It looks hard.
- GitHub Actions also has the programming language feature in their config file. First they supported the Ruby feature by themselves. (See this repo). But now the Ruby project supports the feature instead of GitHub Actions. (See this repo). In my impression the GitHub Actions has more diverse ecosystem by the contributions of the 3rd party’s software, such as this feature - setup-buildx-action by Docker.
We can learn a proper balance about what FW should support from this case.