Skip to content

Another Session on "Why Going Open Source?”

Peter SmulovicsMorgan Stanley

Supply ChainThe Linux Foundation24 minIntermediateOpen on YouTube ↗

Provides another Session on Why Going Open Source?” and evaluates key implications for security practitioners.

Summary

### Overview In this talk, Peter Smalovic shares perspectives and concrete enterprise use cases for open source software (OSS) based on his experience, including 11 years at Morgan Stanley (and previously 10 years at Microsoft). Beyond the traditional, surface-level arguments for open sourcing software—such as recruitment and marketing value—Smalovic explores how enterprises can unlock tangible business, architectural, and operational advantages. Morgan Stanley maintains over 35 active projects on GitHub, and this session details how an open source strategy enables seamless vendor integration, strategic industry roadmapping, flexible staff augmentation, and standard tooling adoption.

### Key Topics - **Beyond Brand Marketing & Hiring:** While an open source portfolio offers marketing and recruiting appeal, its operational and architectural benefits are far more significant. - **Pluggable Architecture:** Enterprises do not need to own every line of code; designing extensible, pluggable platforms allows swapping between open source and proprietary/commercial vendor components while managing risks such as software supply chain attacks. - **Vendor Integration Without Red Tape:** Open source libraries provide public integration points that enable commercial vendors to trial and demonstrate tools directly inside enterprise architectures without upfront non-disclosure agreements (NDAs) or bureaucratic delay. - **Influencing Vendor Product Roadmaps:** Open sourcing strategic frameworks allows financial services firms to signal specific industry needs (e.g., hybrid desktop/web applications) and steer third-party vendor strategies. - **Streamlining Staff Augmentation:** Leveraging open source projects enables enterprise engagements with international consultancies without requiring corporate network logins, internal tool onboarding, or standard institutional red tape. - **Tooling Standardization:** Working in public ecosystems forces adoption of industry-standard DevOps tools (e.g., GitHub) rather than relying on insular internal enterprise solutions.

### Technical Details & Use Cases - **Desktop.js for Rapid Vendor Evaluation:** Desktop.js was created as an open source common API allowing developers to write an application once and execute it across diverse UI containers (both proprietary and open source). When a third-party vendor pitched a UI component, they used Desktop.js in their demo. Because of the open API, the Morgan Stanley team took the demo URL and tested it live within their internal proprietary environment during the pitch itself, removing integration doubts and accelerating procurement. - **Strategy Alignment via Project Compose:** Smalovic and Brian Ingenito drafted a UI strategy published via an open source project named Compose. This influenced an external vendor's leadership (noted by their VP/Director of Project Management) to pivot toward hybrid applications merging web and native technologies, culminating in a joint public showcase. - **Staff Augmentation with Turntable:** Morgan Stanley engaged Turntable, a consultancy based in Accra, Ghana, to work on an open source project called Crossroads (with two follow-up projects added later). By scoping the work entirely in open source, the external engineers avoided logging into internal systems, circumventing corporate onboarding friction, mandatory trainings, and compliance hurdles while paying market consulting fees. - **Internal vs. External Contributions:** Smalovic noted Morgan Stanley contributed nearly 200 pull requests to external projects within the year. However, hosting self-owned projects offers tighter governance, licensing control, and avoidance of external project friction or legal ambiguities (such as maintainers cherry-picking commits without PR disclaimers).

### Takeaways To scale enterprise open source, organizations need dedicated leadership—specifically an empowered Head of Open Source—backed by appropriate legal support (such as working with organizations like FINOS) to navigate paperwork, sandbox environments, and compliance. Rather than focusing strictly on project count, enterprise open source efforts should focus on pluggable architecture, quality, and using open repositories as vehicles for vendor collaboration and flexible resourcing.

Related talks