SCIP is an academic solver built to be taken apart

One solver, several problem classes, and a claim about speed

The README's opening claim is specific and worth quoting accurately rather than paraphrasing into a marketing line. SCIP is described as currently one of the fastest academically developed solvers for mixed integer programming and mixed integer nonlinear programming. The word academically is the qualifier that shapes everything, because it distinguishes SCIP from the commercial MIP solvers it is compared against, and it tells you what kind of project this is. Alongside that, the README says SCIP provides a highly flexible framework for constraint integer programming, for branch-cut-and-price, and that it can optionally be configured to solve mixed-integer linear programs in a numerically exact solving mode. Those three capabilities, a general MIP and MINLP solver, a framework for building constraint integer programs, and a branch-cut-and-price framework, are what a user is choosing between, and they pull in different reasons to adopt.

Control of the solving process is the actual product

The sentence the README puts last is the one that explains the design. SCIP allows for total control of the solution process and access to detailed information down to the guts of the solver. That is a research framework promise, not a user interface promise. A commercial solver gives you a model, a time limit and a solution; SCIP is built so that the branching rule, the cut selection, the primal heuristics and the constraint propagators are components you can configure, replace or instrument. The topic tags on the repository reflect the same emphasis, listing constraint-programming, integer-programming, minlp, minlp-solver, mip, mip-solver and scip. If you are writing a paper about a new cut or a new propagation scheme, this is the property you care about. If you want a solver to hand you a good bound on a scheduling problem tomorrow morning, this is a much larger commitment than you want to make.

Building from source is the normal route

There is no package manager entry and no configure-and-make one-liner in the README. Installation is delegated to a separate INSTALL.md file and to the online installation documentation, which is the pattern you would expect from a project of this size, where the build matrix spans platforms and compilers. The repository layout confirms the scale. There is a CMakeLists.txt and a CMakePresets.json at the root alongside the Makefile, so the Makefile is a wrapper that drives CMake rather than a hand-rolled build, and there are separate directories for the solver sources in src/, the build rules in make/ and cmake/, the documentation in doc/ and tex/, the tests in tests/, the static analysis in check/, lint/ and pclint/, the shipped applications in applications/, and the example problems in examples/. There are also suppressions files for cppcheck and Valgrind, which is a signal about the project's static analysis expectations.

The examples directory is a catalogue of problem classes

The examples are the clearest guide to what the solver is used for, and the list of directories is a good index of the standard benchmark problems. There is a Binpacking example, a Sudoku example, a Travelling Salesman Problem directory and a Vehicle Routing Problem directory, a Queens example, a Single-Cluster Facility Location Problem directory, a LennardJones example, a Mixed Integer Programming Solver example, a Linear Ordering Problem directory, a Generalised Minimum Cost Flow example, an Eventhdlr example, a Relaxator example and a CallableLibrary example. The names of the last three tell you what the framework API is for: a handler example, a relaxation example and a callable library example, which are the extension points a user plugs their own code into. There is also a README explaining how to install and run the examples, a makeall.sh, a makeallclean.sh, a makedoc.sh and a maketestallexamples.sh, and an xternal_examples.c file for the cases sourced from outside the tree.

The licence is Apache-2.0, and the copyright is ZIB

The licence is straightforward for a solver of this kind: Apache-2.0, which is permissive and includes an explicit patent grant, and the licence field in the repository metadata is recorded as such. The top-level layout is: The copyright line in the Makefile header names the holder, with Copyright (c) 2002-2026 Zuse Institute Berlin (ZIB), and the same Apache 2.0 text is reproduced in the header comment. That combination of a permissive licence and an academic copyright holder is the normal arrangement for research software from a university institute, and it means a commercial user can embed SCIP without a negotiation. The long copyright range in the header, starting in 2002, is also a quiet indication of the project's age, which matters for reading the code and for judging how the component interfaces have been shaped over two decades of development.

The canonical repository is not on GitHub

This is the practical detail that catches people out. The README states that the original instance of the repository is hosted at git.zib.de, and that a read-only mirror is available at github.com/scipopt/scip. The mirror is where most people will find the code, the issue tracker and the release tags, and it is convenient for cloning. It is not where the authoritative history lives, and the two are not interchangeable for contribution purposes. There is a .gitlab-ci.yml and a .gitlab/ directory in the tree, which is the tell: continuous integration is defined for the GitLab instance, so the mirror's own CI is not the project's CI. The README also routes documentation and downloads through scipopt.org, with online documentation of the code, downloads of official releases and binaries for various platforms, release reports and scientific articles describing the algorithms behind SCIP, and guidance on how to cite SCIP in scientific publications. That last item is a reminder that this is a research tool with a citation culture attached to it.

Where it is the wrong tool, and what to use instead

Two cases stand out. The first is a production scheduling problem where you need a solver with a support contract, a proven performance record on your instance class and someone to call when the bound stalls. The academically developed framing in the README is an invitation to instrument and modify, and it is not a support model. The second is a mixed-integer linear program with a clean rational solution, where you want the answer today: the numerically exact solving mode exists but is optional and off by default, and the whole toolchain is a from-source build. The practical alternative in that case is a commercial MIP solver, which trades the ability to change the algorithm for vendor performance and support. The genuine alternative in the research case is not a commercial solver at all but simply writing the branch-and-cut loop yourself, which is the comparison SCIP is implicitly offering, and which is exactly what a thesis or a conference paper about a new cut requires.

Editorial conclusion

SCIP suits a researcher or an engineer who needs to understand or change how a solver works, who wants branch-cut-and-price components they can swap, and who needs the numerically exact solving mode for a rational-arithmetic problem. It does not suit someone who wants a commercial solver with a support contract, and it does not suit a build pipeline that expects a single configure and make. Before adopting, read INSTALL.md and the online installation documentation, plan for a compiler and CMake rather than a binary, and note that the last push to the repository was on 2026-10-20 with v10.1.0 released on 2026-09-18.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. scipopt/scip on GitHub