How to hire OCaml developers in 2026: A sourcing guide

OCaml is a statically typed, compiled functional language from the ML family. Its type system is sophisticated enough for academic research; its runtime is fast enough for high-frequency trading. Jane Street, the quantitative trading firm, runs over 30 million lines of OCaml and generates $20.5 billion in annual revenue on it. Meta uses OCaml for Flow (their JavaScript type checker) and Infer (a static analysis tool that catches bugs in Facebook and Instagram's mobile apps). Ahrefs processes the entire web — billions of pages — with an OCaml backend. These are not toy deployments. They are some of the most demanding software systems in production.

The developer pool, though, is vanishingly small. The Stack Overflow 2025 Developer Survey puts OCaml at 1.2% overall usage and just 0.9% among professional developers — roughly 5,000 to 15,000 active practitioners worldwide. Elixir has around 100,000. Go has 3 to 4 million. Python has 16 million-plus. OCaml may have the smallest talent pool of any language running critical production infrastructure at billion-dollar companies.

We touched on OCaml in our niche language sourcing guide. This is the deep dive — the specific repositories, signals, ecosystem dynamics, and sourcing strategies that work for a language where the entire community could fit in a mid-sized conference hall.

This guide covers where OCaml developers contribute on GitHub, what separates deep expertise from surface-level familiarity, the gravitational pull Jane Street exerts on the entire ecosystem, and how to build a sourcing workflow for the most constrained talent market in software engineering.

The OCaml developer market in 2026

The numbers tell a stark story. At 0.9% professional usage in the Stack Overflow survey, OCaml's working developer population is genuinely tiny. Opam, OCaml's package registry, has approximately 4,453 packages. npm has over 2 million. PyPI has over 500,000. Even Hex.pm (Elixir's registry) has tens of thousands. You could source from opam package authors alone and cover a meaningful percentage of the entire community. When the package registry has fewer entries than most languages' top-100 packages have combined dependents, you are in a fundamentally different talent market.

Jane Street dominates this market in a way no single company dominates any other language ecosystem. They employ over 500 OCaml developers, which may be 5 to 10 percent of all OCaml developers worldwide. They maintain janestreet/core (an alternative standard library), janestreet/async (a concurrent programming library), and dozens of other foundational packages the ecosystem depends on. Their median software engineer compensation is $368,000, with the highest reported figure at $632,000. When one employer can offer $400,000-plus to write the language you love, every other potential employer has a compensation problem.

This is the Jane Street factor. It shapes every aspect of OCaml hiring. They set compensation expectations almost no other company can match. They retain aggressively. They maintain so much of the ecosystem's infrastructure that a significant fraction of OCaml open source activity on GitHub traces back to Jane Street employees. If you are hiring OCaml developers, you are competing against the gravitational center of the entire language community, not just other companies.

Beyond Jane Street, OCaml's production footprint concentrates in a few domains. Meta uses it for developer tools — Flow and Infer are both substantial codebases. Ahrefs runs its entire backend in OCaml, processing web-scale data for SEO analytics. Tezos and Mina Protocol chose OCaml for blockchain implementations where formal verification and correctness matter. Tarides builds MirageOS (a library operating system for unikernels) and Irmin (a Git-like distributed database). Citrix uses OCaml for XenServer's toolstack. LexiFi uses it for financial derivative pricing. Semgrep's code analysis engine is built in OCaml. Bloomberg, SimCorp, and Docker have OCaml components. What these companies share: they chose OCaml because a bug in their system has outsized consequences — lost money, security vulnerabilities, or incorrect analysis at scale.

The OCaml Software Foundation (OCSF) provides organizational support for the ecosystem. Its platinum sponsors are Ahrefs and Jane Street. Bloomberg is a gold sponsor. A handful of companies fund and sustain most of OCaml's open source infrastructure. When three companies account for most of the language's institutional support, the community's center of gravity is narrow and well-defined.

By domain, OCaml engineers cluster in quantitative finance and trading systems, where type safety and performance are existential requirements. Compilers, type checkers, and static analysis tools — OCaml's type system makes it a natural fit for building other type systems. Systems programming and infrastructure where formal correctness guarantees matter. Blockchain and distributed systems that need verifiable behavior. Web-scale data processing at companies like Ahrefs. None of these overlap much with the mainstream web development market. An OCaml developer is almost never competing for the same roles as a React or Django developer.

Where OCaml developers contribute on GitHub

Because the OCaml community is so small, individual contributions carry outsized signal. A developer who has merged a pull request into ocaml/ocaml has directly shaped the language — there are very few such people. GitHub is the most effective sourcing channel for OCaml engineers because the ecosystem is almost entirely open source and the community is small enough that contributions are individually traceable.

The compiler and standard library. ocaml/ocaml is the reference implementation — the compiler, type checker, runtime, and standard library. Contributors here work at the deepest level of the language. Changes to the OCaml compiler require understanding type theory, compiler design, and the specific constraints of OCaml's runtime model. Even well-written issue reports and design discussions on this repo indicate someone who understands the language at a foundational level.

Build tooling and package management. ocaml/dune is the standard build system for OCaml projects. It handles compilation, dependency management, and cross-compilation. ocaml/opam is the package manager. Contributors to these projects understand the practical engineering side of OCaml — how projects are structured, how dependencies are resolved, and how the toolchain fits together. Dune contributors in particular tend to be experienced practitioners who have built enough OCaml projects to understand build system pain points.

Jane Street's ecosystem. janestreet/core replaces OCaml's minimal standard library with a comprehensive alternative. janestreet/async provides concurrent and asynchronous programming primitives. Jane Street publishes dozens of other packages — janestreet/ppx_jane, janestreet/base, janestreet/expect_test — that form a parallel ecosystem within OCaml. Contributors to these repos outside of Jane Street itself are rare and worth paying attention to: they demonstrate the ability to work with Jane Street's idioms, which matters for any company whose OCaml codebase uses Jane Street libraries (many do).

Systems programming and unikernels. mirage/mirage is a library operating system that builds unikernels — specialized, single-purpose virtual machine images compiled directly from OCaml source code. MirageOS strips out everything a traditional OS provides and replaces it with OCaml libraries for networking, storage, and I/O. Contributors understand systems programming at the OS level: network stacks, block device drivers, TLS implementations, where the language runtime meets hardware. Tarides maintains much of this ecosystem. A MirageOS contributor is a systems engineer who happens to work in OCaml, not just an OCaml developer.

Type systems and static analysis. facebook/flow is Meta's JavaScript type checker, written in OCaml. facebook/infer is their static analysis tool for finding bugs in C, C++, Objective-C, and Java code before deployment. semgrep/semgrep is a code analysis engine used across many organizations. Contributors to these projects combine OCaml expertise with deep knowledge of program analysis, type theory, and compiler internals. These are among the most technically demanding OCaml codebases outside of Jane Street.

Opam package authors. With approximately 4,453 packages on opam, the registry is small enough that prolific package authors represent a significant fraction of the community. A developer who maintains multiple well-documented opam packages with real downstream dependents is almost certainly a senior OCaml practitioner. Cross-referencing opam package metadata with GitHub profiles is a manual but effective sourcing method — and because the registry is small, it is feasible in a way that searching npm or PyPI never would be.

Quality signals in OCaml code

OCaml has one of the most expressive type systems of any production language, and expertise shows in how a developer uses it. The gap between "writes OCaml that compiles" and "writes OCaml that uses the type system for correctness" is enormous. General seniority signals on GitHub apply, but OCaml has specific markers worth knowing.

The module system. OCaml's module system — functors, first-class modules, module signatures — is its most distinctive feature. Nothing in Haskell, Rust, or any mainstream language directly corresponds to it. Functors are modules parameterized by other modules, allowing a level of abstraction and code reuse that type classes and generics do not provide. A developer who uses functors to build composable, reusable abstractions understands OCaml at a level that cannot be faked. If you see a codebase that uses first-class modules to select implementations at runtime based on configuration, or functors to abstract over storage backends, that developer has internalized what makes OCaml different.

GADTs (Generalized Algebraic Data Types). GADTs extend OCaml's algebraic data types with type-level constraints checked at compile time. They let you encode invariants directly in the type system — for example, ensuring that a well-typed expression can only produce a well-typed result. Most OCaml developers never use GADTs. When you see them used correctly, particularly for type-safe interpreters, serialization formats, or protocol implementations, it points to a developer with genuine type theory background.

Ppx preprocessing. Ppx (PreProcessor eXtension) is OCaml's compile-time metaprogramming system. Ppx plugins transform the abstract syntax tree during compilation, generating code for serialization, testing, logging, and other cross-cutting concerns. Writing ppx transformers requires understanding OCaml's AST representation and the compilation pipeline. Jane Street's ppx_jane is a collection of these transformers that many OCaml projects depend on. A developer who writes custom ppx plugins — not just uses existing ones — understands OCaml's compilation model at a deep level.

Pattern matching and exhaustiveness. Like all ML-family languages, OCaml uses pattern matching extensively. But experienced OCaml developers rely on exhaustiveness checking — the compiler's ability to warn when a match expression does not cover all possible cases. Code that avoids wildcard patterns (_) in favor of explicit case enumeration is a quality signal: the developer is using the compiler as a correctness tool, ensuring that adding a new variant to an algebraic type will produce compilation warnings everywhere it needs to be handled. This is a discipline choice, not a syntax choice, and it separates engineers who use OCaml's type system defensively from those who just happen to write code in OCaml.

Error handling with result types. Experienced OCaml developers use Result.t (or Or_error.t in the Jane Street ecosystem) for recoverable errors rather than raising exceptions. This makes error paths explicit in the type signature — a function that returns (value, error) result forces the caller to handle both cases. A codebase that uses exceptions for control flow is written by someone bringing habits from Python or Java. A codebase that pushes error handling into the type system is written by someone who understands why OCaml's type system exists.

Testing patterns. OCaml has several testing approaches: inline expect tests (popularized by Jane Street), Alcotest for unit testing, and QCheck for property-based testing. Jane Street's expect test framework is particularly interesting as a signal — it generates expected output inline in the source file, making tests self-documenting and easy to update. A developer who uses expect tests and property-based testing shows both ecosystem familiarity and a concern for correctness that goes beyond "it compiles, so it works."

The OCaml ecosystem: OCaml 5, effects, and multicore

OCaml 5 is the biggest change to the language in its 30-year history. It fundamentally changes what OCaml can do. For sourcing, it matters because it splits the community: developers adapting to the new runtime, and developers still working with OCaml 4 idioms.

The headline feature is multicore support. Before OCaml 5, the runtime had a global lock (similar to Python's GIL) that prevented true parallel execution. OCaml 5 removes it entirely — OCaml programs can now use multiple CPU cores for the first time. This opens the language to workloads that previously required dropping down to C or choosing a different language. Developers contributing to multicore-related libraries, writing parallel algorithms in OCaml, or adapting existing libraries for thread safety are at the cutting edge of the ecosystem.

Algebraic effects are the other major addition. Effects provide a structured way to handle side effects — I/O, state, exceptions, concurrency — without monads (Haskell's approach) or colored functions (what async/await introduces in JavaScript, Python, and Rust). Code using effects looks synchronous but can be suspended, resumed, and composed. No other production language has algebraic effects as a first-class feature. Developers experimenting with effects handlers, building effect-based libraries, or contributing to the effects system in ocaml/ocaml itself are working on problems with no precedent in mainstream software engineering.

The transition to OCaml 5 creates a specific sourcing opportunity. Libraries need multicore safety updates. New concurrency patterns need to be worked out. The ecosystem is in flux, and developers actively contributing to this transition — updating packages for OCaml 5 compatibility, writing effect handlers, building multicore-safe data structures — are showing both current engagement and the ability to work with genuinely novel programming concepts.

The community is small but deeply technical. The OCaml Workshop, co-located with ICFP (the International Conference on Functional Programming), is the primary academic and industry gathering. Discuss.ocaml.org is the main community forum. The Tarides blog publishes detailed technical content about MirageOS, Irmin, and OCaml development. Because the community is so small, these channels are not noise — they are traceable lists of engaged practitioners. A developer who presents at the OCaml Workshop or writes substantive posts on discuss.ocaml.org is visible and findable.

One dynamic worth understanding: the ReasonML and ReScript connection. ReasonML was an alternative syntax for OCaml created at Meta, designed to feel familiar to JavaScript developers. ReScript evolved from ReasonML as a separate language targeting JavaScript compilation. Developers who worked with ReasonML have OCaml exposure — they used OCaml's type system and module system through a different syntactic lens, and some have since transitioned to native OCaml work. This is an adjacent talent pool that gets overlooked. Similarly, Haskell developers share enough type system DNA with OCaml that the transition path is well-established, particularly for developers with ML family experience.

How to search for OCaml developers on GitHub

Searching for OCaml developers on GitHub requires calibrating for extreme scarcity. The strategies that work for JavaScript, Python, or even Go — where you can filter by language and still get thousands of active results — break down for a community of 5,000 to 15,000. The niche language sourcing strategies we covered previously apply, but OCaml pushes them to their limits.

Language filter. Filtering by language:ocaml in GitHub repository or code search surfaces developers who actively write OCaml. Because the community is so tiny, nearly every result is a genuine practitioner — very little noise from tutorial completers or abandoned side projects. The signal-to-noise ratio is the highest of any language you will search for. But the absolute numbers are correspondingly small: 50 to 200 active contributors to any given area, not thousands.

Opam package authors. Opam has approximately 4,453 packages — small enough to be systematically searchable. Package metadata includes author information and source repository links. Developers who maintain well-documented opam packages with real downstream dependents are senior practitioners by definition. In a community this small, maintaining public infrastructure is a strong signal of both expertise and engagement. Cross-referencing opam packages with GitHub profiles is feasible precisely because the registry is small.

Jane Street's open source. Jane Street publishes hundreds of packages under the janestreet GitHub organization. External contributors to these packages are rare and worth noting — they demonstrate familiarity with Jane Street's coding style and library ecosystem, which many OCaml shops use. But be aware that many contributors to Jane Street packages are Jane Street employees, and recruiting from Jane Street is a specific challenge with specific dynamics (extremely high retention, extremely high compensation).

Academic connections. OCaml has deeper ties to academia than most production languages. INRIA (the French national research institute) created the language and still contributes to its development. Many OCaml developers came through academic computer science programs, particularly in France, the UK, and at universities with strong programming languages research groups. GitHub profiles that show contributions to both academic and industry OCaml projects suggest developers who can move between theory and practice — a rare and useful combination.

Adjacent language signals. The most productive way to expand your OCaml candidate pool is through adjacent communities. Haskell developers share the ML family's type system concepts: algebraic data types, pattern matching, type inference, parametric polymorphism. F# is essentially OCaml for .NET and shares syntax and semantics. ML researchers working in Standard ML or other ML variants have directly transferable knowledge. ReasonML and ReScript developers have worked with OCaml's type system through an alternative syntax. Any of these developers can become productive in OCaml faster than someone coming from Python, Java, or TypeScript.

Contribution recency. In a community of 5,000 to 15,000, "active" means something different than it does for mainstream languages. An OCaml developer who has committed meaningful code in the last 12 months is active in one of the smallest professional language communities around. Widen your recency window compared to what you would use for larger ecosystems. Someone who contributed to ocaml/ocaml eight months ago is not stale — they are one of a very small number of people who have ever contributed to that repository.

A practical OCaml sourcing workflow

Here is what works, from initial discovery to first outreach. The difference from sourcing for larger ecosystems: your total addressable pool may be a few hundred people, and every step has to account for that.

Step 1: Define the technical profile precisely. "OCaml developer" is too broad given the extremes within the community. Are you hiring for compiler or type system work (language tooling, static analysis)? Trading and financial systems (Jane Street-style quantitative infrastructure)? Systems programming (MirageOS, unikernels, low-level runtime work)? Web-scale data processing (Ahrefs-style backend systems)? Blockchain and formal verification (Tezos-style smart contract platforms)? Each maps to different GitHub repositories, different opam packages, and a different slice of the already tiny community. A MirageOS contributor and a Jane Street Core contributor may both write OCaml daily but live in completely different niches.

Step 2: Identify target repositories. Based on the technical profile, list the GitHub repositories where your ideal candidate would contribute. For compiler and language work: ocaml/ocaml, ocaml/dune, ocaml/opam. For trading infrastructure: janestreet/core, janestreet/async. For systems programming: mirage/mirage. For static analysis: facebook/flow, facebook/infer, semgrep/semgrep. Map the role to the repos. Given the community's size, your target repo list will be short — that is expected.

Step 3: Extract contributors. Use GitHub's contributor graphs or tools like riem.ai that index GitHub event data at scale. Focus on recent contributors with meaningful contributions: code changes, reviews, and design discussions, not documentation typo fixes. Your initial list may be 10 to 30 people for a specific niche. That is not a sign of failure — it is an accurate reflection of how few people work in this space. Every name on that list is worth investigating.

Step 4: Evaluate profiles. Review each candidate's GitHub profile for the quality signals described above: module system usage (functors, first-class modules), GADT usage, ppx development, exhaustive pattern matching, result-type error handling. Seniority signals like code review participation and cross-project contributions matter even more in a community this small because individual reputations are well-known. Check whether they maintain opam packages, contribute to multiple OCaml projects, and participate in design discussions on the OCaml GitHub repos or discuss.ocaml.org.

Step 5: Expand to adjacent talent pools. This step is not optional for OCaml. The pure OCaml pool is too small for most hiring needs. Haskell developers are the closest adjacent community — they understand algebraic data types, type inference, pattern matching, and functional programming at a deep level. F# developers work in a language that is OCaml's direct descendant on .NET. ML researchers (Standard ML, dependent type theory) have the theoretical foundations. ReasonML and ReScript developers have already used OCaml's type system. Search for developers whose primary language is Haskell, F#, or Scala but who have OCaml repositories or contributions — they may be further into the transition than their profile suggests. Do not require "3 or more years of OCaml experience." In a community of 5,000 to 15,000, that requirement eliminates most of your viable candidates, and the remaining few are likely at Jane Street earning $400,000.

Step 6: Craft outreach that acknowledges the ecosystem. OCaml developers get far fewer recruiter messages than React or Python developers, but the ones they do get are almost always poorly targeted. Generic outreach is instantly dismissed in a community this small and technical. Effective developer outreach for OCaml must reference specific contributions: "I saw your functor-based abstraction over storage backends in your MirageOS block device driver — we're building a similar pluggable architecture for our data pipeline and your approach to module signatures is exactly what we need." You also have to address the Jane Street question directly. If you cannot match their compensation, say so honestly and explain what you offer instead: interesting technical problems, open source contribution time, architectural ownership, or a domain that Jane Street does not operate in.

Step 7: Scale with tooling. The manual workflow above works, but you will exhaust your target repos quickly in a community this small. Tools like riem.ai automate the discovery and evaluation steps by analyzing 30 million-plus GitHub events per month and surfacing OCaml developers based on actual contribution patterns. Instead of manually cross-referencing opam packages and reviewing profiles one by one, you describe the technical profile in natural language ("OCaml developers who contribute to compiler tooling or static analysis and have experience with the module system and ppx preprocessing") and get a ranked list of candidates with contribution summaries and quality scores. For a language with this few practitioners, automated discovery finds candidates you would miss manually.

Frequently asked questions

How many OCaml developers are there?

Roughly 5,000 to 15,000 active OCaml developers globally as of 2026, making it the smallest talent pool of any language with significant production adoption. The Stack Overflow 2025 Developer Survey shows OCaml at 1.2% overall usage and 0.9% among professional developers. For context, that is roughly one-tenth the size of the Elixir community and one-hundredth the size of Go. Jane Street alone may employ 5 to 10 percent of all OCaml developers worldwide. The pool is so small that opam, OCaml's package registry, has approximately 4,453 packages — sourcing from package authors would cover a meaningful percentage of the entire community.

What salary should I expect to pay OCaml developers?

OCaml compensation is dominated by Jane Street, which reports a median software engineer salary of $368,000 and a highest reported compensation of $632,000. These figures distort the broader OCaml market because Jane Street employs such a large fraction of all OCaml developers. Outside of quantitative finance, OCaml developers at companies like Ahrefs, Tarides, and LexiFi typically earn $150,000 to $250,000 for senior roles, depending on location and domain. The fundamental challenge is that Jane Street sets compensation expectations that almost no other employer can match. Any company hiring OCaml developers is competing against a firm that generates $20.5 billion in annual revenue and pays accordingly.

What is OCaml actually used for in production?

OCaml is used in domains where correctness, performance, and type safety are non-negotiable. Jane Street runs its entire trading infrastructure — over 30 million lines of OCaml — on it. Meta uses OCaml for Flow (JavaScript type checker) and Infer (static analysis tool that catches bugs in mobile apps before deployment). Ahrefs runs its entire web crawling and SEO analytics backend in OCaml. Tezos and Mina Protocol use OCaml for blockchain implementations where formal verification matters. Semgrep uses OCaml for its code analysis engine. Docker has OCaml components. Citrix built XenServer's toolstack in OCaml. LexiFi uses it for financial derivative pricing. Bloomberg and SimCorp have OCaml components in their financial systems. The common thread is systems where a bug has outsized consequences — lost money, security vulnerabilities, or incorrect analysis at scale.

How does OCaml compare to Haskell for hiring?

OCaml and Haskell share ML family roots and attract similar developers, but the hiring dynamics differ. Haskell has a larger community (roughly 3 to 5 times OCaml's size) but fewer large-scale production deployments. OCaml has a smaller community but deeper production concentration — Jane Street's 30 million-plus lines of OCaml is one of the largest functional programming codebases anywhere. Haskell developers are strong adjacent candidates for OCaml roles because type systems, pattern matching, and algebraic data types transfer directly. The main differences: OCaml uses strict evaluation (Haskell uses lazy evaluation), and OCaml's module system (functors and first-class modules) has no direct Haskell equivalent. A Haskell developer can become productive in OCaml relatively quickly, but mastering the module system takes real project experience.

What OCaml projects should I look for on GitHub?

For the language itself: ocaml/ocaml (the compiler and standard library). For build tooling: ocaml/dune (the standard build system) and ocaml/opam (the package manager). For Jane Street's ecosystem: janestreet/core (standard library replacement) and janestreet/async (concurrent programming). For systems programming: mirage/mirage (library operating system for unikernels). For type systems and static analysis: facebook/flow (JavaScript type checker) and facebook/infer (static analysis). For code analysis: semgrep/semgrep. Contributors to any of these repositories are working on infrastructure the OCaml ecosystem depends on. Given the community's tiny size, even moderate contributions to these projects point to a developer with real production experience.

How long does it take to hire an OCaml developer?

Expect 60 to 120 days minimum, and potentially longer for senior roles requiring deep module system or compiler expertise. The bottleneck is entirely supply — there are simply very few OCaml developers, and most are already employed at companies that are difficult to recruit from. Jane Street retains aggressively with compensation that most companies cannot match. The most effective strategy is to widen the candidate pool to include Haskell developers, F# developers, ML researchers, and ReasonML/ReScript developers, all of whom can transition to OCaml with the right onboarding. Sourcing from GitHub contribution data, opam package authors, and OCaml Workshop or ICFP attendee lists can surface candidates who are invisible on traditional job boards.