+1 to reaching out to David to hear his take on it. TBH I am a bit surprised that the Julia community decided to go all-in on a platform that is controlled by one company, but ¯_(ツ)_/¯
@sgibson91 I think it’s worth disentangling a few different “aspects” of open source (as I understand it) and how each relates to VSCode.
Open components - in this respect, VSCode does decently well. Many of the underlying components (Monaco being the most well-known example) are openly-licensed. However, as the JupyterLab team learned when they tried to integrate Monaco with JupyterLab, many of these components make assumptions about VSCode infrastructure being present, so aren’t designed to be super easily/readily reusable elsewhere. That said, I think when people say “VSCode is open source” this is really the only thing that it appliesto.
Open governance - in this respect, VSCode does poorly. There is no open governance of VSCode development, nor of the open source components underneath. Those are all Microsoft products and driven by Microsoft roadmaps/PMs/etc. As @matthew.brett mentions - right now Microsoft has decided to align itself with open source (and making a strong marketing push to brand VSCode as “open source” for various reasons). What will that look like in 1/2/5/10 years? History says that relying on a gigantic company with monopolistic tendencies is an anti-pattern if you care about public goods and collective power.
Open products - in this respect, VSCode also does OK but not great. VSCode is a proprietary distribution that contains a collection of open source and proprietary components. Sure you can fork VSCode and keep only the open source parts (that’s what VSCodium is). But then you realize that there are actually a lot of proprietary things interwoven in VSCode in subtle ways. E.g., as others have mentioned the “real time collaboration” API is proprietary, and many of the extentions that ship with VSCode are proprietary. As time goes on, I suspect VSCode will change the ratio of “open source to proprietary” extensions within VSCode such that the “open fork” versions will become relatively more underpowered.
A good example of the tensions that can arise with this are actually related to Julia notebooks. In the PR where they propose creating
jlnb files, David actually mentions that one reason they’re considering
.jlnb is because the
.ipynb format in vscode is managed by the vscode-python team. In other words, Jupyter’s vision of a truly multi-language and multi-stakeholder layer of infrastructure is potentially going to be fractured because a product team inside of Microsoft is building “Jupyter” tooling that is too Python-specific, and on a platform that is becoming so popular that it is influencing decisions about Jupyter tooling in a way that Jupyter has no say into.
Or to put it shortly if VSCode were translated into the Jupyter ecosystem, it’d be like if:
- JupyterLab was a product of a single large company called
The Jupyter Corporation
- This company also ran a totally proprietary version of JupyterHub on its own cloud
- This company also controlled the most popular platform for doing open source development, and could use that platform to encourage the use of these products above other options.
- All development of core JupyterLab components, APIs, and key extensions were done by this company
- JupyterLab shipped the
pip install jupyterlab version with a bunch of proprietary extensions pre-installed
- JupyterLab encouraged communities to fork it and create their own JupyterLabs if they didn’t want the proprietary stuff
- JupyterLab encouraged a lot of open source development and experimentation within jupyterlab’s ecosystem, but where the ecosystem’s platform was controlled by
The Jupyter Corporation.
Don’t get me wrong, I love VSCode and use it all the time. From an engineering perspective it is super impressive, and I also appreciate all of the effort they’ve put into making it very extensible (and easy to extend). And I should also be clear that all of this is totally Microsoft’s prerogative, there’s no reason that they can’t operate in this way, it is IMO in their interests as a company. I just think we should be realistic about it’s role in the arc of “the open community” and its relationship to research and education. I think it’s not realistic to think of Microsoft as “a friend of open source” but more like “temporarily aligned with the interests of open source” - it may be true now but the last 3 years are a tiny blip in the history of Microsoft’s culture. Whether it is Microsoft/Google/Amazon/etc we want the infrastructure and platforms in our community to be governed by the commons, not by any single entity that doesn’t have a properly open and multi-stakeholder governance model.
note: Theia is I think an interesting project here, because it basically re-uses a lot of the VSCode components but packages them in a distribution that is also open source and designed for composability and reusability. That distribution is managed by the Eclipse Foundation, which is a multi-stakeholder group. I’d feel a lot more comfortable if we found ways to empower the Theia/Eclipse community, rather than to work within the sandbox that Microsoft gives us.