Proposed: Jupyter FS

[vidartf-jpmc]

Contribution Prerequisites

• I have read FINOS Contribution Requirements.
• I confirm I am contributing on behalf of a FINOS member OR I will seek a maintainer from a member during socialization.
• I have reviewed the FINOS Contribution Process.
• I have reviewed the FINOS Project Lifecycle stages.
• I am familiar with FINOS Governance and Maintainer Responsibilities.

Target Lifecycle Stage

Incubating - #423

FINOS Member Organization Name

JP Morgan Chase

Name

Jupyter FS

Slug

jupyter-fs

Business Problem & Solution

Financial services firms operate in environments where analysts, quants, traders, and developers routinely need to access notebooks, datasets, models, and code that live across many different storage systems — local disks, shared network drives (SMB/CIFS), cloud object stores (S3, Azure Blob, GCS), enterprise content systems, and internal artifact repositories. JupyterLab, which has become a standard interactive computing environment across the industry for research, model development, and data analysis, by default ships with only a single local-filesystem browser. This forces users into fragmented workflows: downloading files locally before working with them, juggling multiple tools and credentials, copying data between systems (creating governance, lineage, and data-loss risks), and writing boilerplate code in every notebook just to load remote artifacts.

Jupyter FS solves this by providing a JupyterLab extension and Jupyter Server contents manager that exposes any PyFilesystem2 or fsspec compatible backend as a first-class, browsable file tree directly inside JupyterLab. Users can mount multiple heterogeneous filesystems side-by-side, browse and open files natively, and interact with remote stores using the same UX as local files — with support for credential management (including OS keyring integration) so that secrets do not need to be hard-coded into notebooks. For Financial Services specifically, this means:

• Reduced operational risk and improved data governance: data can be read directly from authoritative stores rather than copied to laptops or shared drives.
• Consistent, auditable access patterns: one extension and one credential model across S3, SMB, OSFS, and other backends, simplifying compliance with internal data-handling and entitlement policies.
• Lower total cost of ownership: a single open-source, pluggable extension replaces a proliferation of custom in-house file connectors that each business line would otherwise build and maintain.

By contributing jupyter-fs to FINOS, the project gains a vendor-neutral home where banks, asset managers, and fintech vendors can collaborate on shared filesystem connectors, security hardening, and enterprise integrations that benefit the entire industry.

Mission Statement

The mission of the project is to enable JupyterLab users to seamlessly browse, access, and manage files across any local or remote filesystem through a single, extensible, and secure interface.

Additional Information (Optional)

No response

Maintainer Team

Name	Affiliation	Email	GitHub Username
Vidar T Fauske	JP Morgan Chase	104149412+vidartf-jpmc@users.noreply.github.com	@vidartf-jpmc / @vidartf
Tim Paine	Point72 - Cubist	3105306+timkpaine@users.noreply.github.com	@timkpaine

Compliance & Requirements Agreement

• I understand that before being able to contribute all maintainers and contributors will need to be covered by a Contributor License Agreement or commits must satisfy the Developer Certificate of Origin (DCO) requirements.
• I confirm that software will be covered by the Apache 2.0 License and any third-party code is compatible.
• I have selected the appropriate lifecycle stage based on that stage's requirements. I agree and commit to the Acceptance & Maintenance Requirements for my target stage.

Administrative Consent & Transfer Authorization

• I agree to grant 'finos-admin' Admin/Owner access to the repository for security auditing and setup.
• I authorize the transfer of this code/repository to the FINOS GitHub organization upon project acceptance.
• I confirm I have the legal authority (individual or corporate) to grant these permissions.

Socialization Acknowledgement

• I understand I may need to socialize this proposal to community@finos.org before a TOC review to gauge community interest.

[timkpaine]

I support this and it's in line with the existing ecosystem of Jupyter (an LF org) tools in FINOS (another LF org).

[TheJuanAndOnly99]

Thank you @vidartf-jpmc for your contribution proposal!

As mentioned in our email conversations, given the project's current maturity, we suggest applying directly to the Incubating Stage. Could you please also submit an accompanying "Project Incubation" issue?

[vidartf-jpmc]

Thanks @TheJuanAndOnly99 ! I did pick "incubating" as the Target Lifecycle Stage here, but didn't realize that triggered another form! Will have a look

[vidartf-jpmc]

Is there an example of a prior such ticket I can use for reference? I can't seem to find any in the issue list.

[TheJuanAndOnly99]

Hi @vidartf-jpmc this is a new process that was just rolled out with the recent update to the FINOS Lifecycle. If anything doesn't make sense to you or if you have questions you can email help@finos.org. It doesn't have to be perfect and we can iterate on it as needed. It's mainly so the TOC can get some more context before their official review.

[vidartf-jpmc]

Thanks for the context. My main question is about the "end-user adaption story". I'm not entirely sure what that is, or who can create it: could I create it for our deployment (in which case I would need clearance to write something up and publish it), or is this required to be from a non-maintainer?

[TheJuanAndOnly99]

@vidartf-jpmc Yes, you can use your own deployment for this. It does not need to come from a non-maintainer. The goal is simply to show that the project is solving a real-world problem for a financial institution.

To help you bypass any corporate or legal bottlenecks, we can be flexible with how you share this:

Keep it private: You can share a confidential write-up directly with the TOC.

Discuss it on a TOC call: If it's easier, we can just have you talk through your deployment use case and scope when you get called up to a TOC call for the presentation.

Note it doesn't need to be an exhaustive whitepaper or an officially published article. A brief summary explaining the problem, how the project solved it, and the general scope (e.g., "deployed in production for our internal data pipeline") is perfect.

[vidartf-jpmc]

Xref: #423

[TheJuanAndOnly99]

Thank you @vidartf-jpmc for submitting the accompanying Incubation issue - #423. I am labeling this as ready for the TOC.