# OpenPBS: the open source job scheduler behind a lot of HPC > OpenPBS is the open source edition of the PBS Professional workload manager, a job scheduler and workload manager for clusters, clouds and supercomputers. Its documentation is unusually community-shaped, its licence is custom rather than a standard one, and its release tags and its commit history tell different stories about how actively it moves. **openpbs/openpbs** — An HPC workload manager and job scheduler for desktops, clusters, and clouds. - Repository: https://github.com/openpbs/openpbs - Website: https://www.openpbs.org - Stars: 809 · Forks: 353 - Language: C - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/openpbs-openpbs ## The same code as PBS Professional, under a different name OpenPBS is the open source project behind PBS Professional, and the naming history explains the version numbers you will see. The README records that in May 2020 OpenPBS became the new name for the PBS Professional Open Source Project, with the same code and easier naming, and that the rename would take several weeks to work through all parts of the project, so references to PBS Pro would persist for a while. PBS Professional refers to the commercial version and OpenPBS to the open source one. What the project is, in its own description, is software that optimises job scheduling and workload management in high-performance computing environments, covering clusters, clouds and supercomputers. The stated audience is the same in both the overview and the tagline: built by HPC people for HPC people. The licence shape follows the same split. The vision section explains that Altair invested in releasing the PBS Professional technology as OpenPBS under an open source licence to meet the needs of the public sector, while continuing to offer PBS Professional under a commercial licence for the private sector. The ambition behind it is a single scheduler for the whole HPC world, with common standards as the lever, and the argument is that the same codebase serving both sectors is the defacto standard the community was missing. So this is not a hobby reimplementation. It is the open source face of a commercial product, and that is the first thing to understand when you evaluate it. ## Five claims, and the mechanisms behind them The overview lists five characteristics, and each one names a mechanism rather than an aspiration. Scalability is described as supporting millions of cores with fast job dispatch and minimal latency, and the README says it has been tested beyond 50,000 nodes. That is the scale target: a scheduler that dispatches quickly across a very large allocation, rather than a queue that works well on one rack. Policy-driven scheduling is the point of having a scheduler at all. It meets site goals and service level agreements by balancing job turnaround time against utilisation, with job placement as the third variable. In other words, the policy is the product, and a site that wants different policies from different groups is the reason this layer exists. Resiliency is described as an automatic fail-over architecture with no single point of failure, where jobs are never lost and continue to run despite failures. Health checks are the mechanism behind that claim, a comprehensive framework that monitors for faults and automatically mitigates them. The flexible plugin framework is the extensibility story. The repository topics list hooks, plugins and provisioning, and the description of the framework is about simplifying administration with enhanced visibility and extensibility, and letting implementations be customised to meet complex requirements. That is how a site adds scheduler hooks, or a provisioner, without forking the scheduler. ## The repository is an autotools project with an RPM spec The source layout tells you this is a long-lived C project with packaging in mind, and it is worth reading before you clone it. The build system is the GNU autotools. There is a configure.ac, a Makefile.am, an autogen.sh and an m4 directory for the macros, alongside buildutils for the build helpers. The source is in src, the tests in test, and the documentation in doc. Packaging is RPM oriented. There is an openpbs.spec and an openpbs.spec.in, where the .in file is the template that the spec is generated from, and an openpbs-rpmlintrc that configures the RPM linting rules. There is also a valgrind.supp suppression file, which tells you the test suite is expected to run under memory checking tools. Continuous integration is configured in two places. There is a Travis build badge pointing at the master branch, and an azure-pipelines.yml at the top level, alongside a ci directory and a .github directory. Two CI systems in a project of this age is not redundancy so much as a transition, with the older one likely still carrying some of the load. The remaining top level files are the ones you would expect from a project with its own legal and community process: a LICENSE file, a PBS_License.txt, a COPYRIGHT file, an INSTALL file, a CONTRIBUTING.md and a CODE_OF_CONDUCT.md, plus a .clang-format for the C sources. ## There is no install guide in the README If you are looking for the instructions to get OpenPBS running, the README does not contain them, and it says so. The opening line tells newcomers to start at the project website, www.openpbs.org, and the rest of the README is about the project, its community and its vision. That is a deliberate division of labour: the website is the front door for documentation and downloads, and the repository is where the code and the tests live. What the repository gives you instead is the pieces a distribution would need. There is an INSTALL file, which is the conventional place for build instructions, an autogen.sh for regenerating the autotools build system, and the RPM spec files for building a package rather than installing from source. A site that already builds software from source on its own clusters has everything it needs to produce an RPM, and a site that does not should start with the website rather than with configure. One thing to keep in mind before you plan an upgrade: the published release tags and the commit history tell different stories. The releases listed for the repository are v23.06.06 from 2023, v22.05.11 from 2022 and v20.0.1 from 2020, while the last push to the repository was on 2026-04-10. Whatever is landing in master is not the same as what the newest tag contains, and which of the two you want depends on whether you want a supported release or the current state of development. ## The community channels are the documentation For a project of this age and this commercial backing, the way knowledge is distributed is unusual enough to be worth describing, because it tells you where the answers to your questions will actually be. There are three forum areas, and they split along audience. Announcements carries the updates that matter to the entire community, the users and site administrators area is for general questions from system admins, engineers and scientists, and the developers area is for technical discussion between developers. If you are running a site, the middle one is the one you will read. Longer reference content sits in the contributor's portal, which the README describes as holding roadmaps, processes, how-to articles, coding standards and release notes, hosted on Confluence. The source code and the test framework are on GitHub, and so is the issue tracker for bugs and feature requests, with the note that the project previously used JIRA and that the older issues live there. The project also states how it wants to work. It describes itself as a community effort and lists the ways in, from answering questions to benchmarking to developing capabilities and tests, and it asks for aggressive openness and inclusiveness alongside aggressive respect and professionalism, with a code of conduct linked. The practical consequence for an adopter is that the documentation is spread across a website, a forum, a wiki and a tracker, and a question asked in the wrong place is a question that stays unanswered. ## OpenHPC is the path into a distribution If you are not building OpenPBS from source, the more likely route into it is through a Linux distribution. The README states that OpenPBS is integrated in the OpenHPC software stack, whose mission is to provide an integrated collection of HPC-centric components that give a full-featured HPC software stack. OpenHPC is a Linux Foundation Collaborative Project, and the project points at the OpenHPC community site and the Linux Foundation itself. That is a meaningful piece of context for anyone evaluating the project. A workload manager is not something you deploy on a laptop and evaluate in an afternoon, because the point of it is to run a queue for a shared resource, which means it has to sit inside a site that already has a provisioning system, a filesystem, an identity source and an operations practice. Integration into a curated distribution means those surroundings are already assembled, and the alternative is assembling them yourself. The other route is the commercial one. The vision section is explicit that PBS Professional continues to be offered under a commercial licence for private sector needs, and that the two are the same codebase. For an organisation that wants the scheduling features with a support contract behind them, that is a legitimate reading of the same technology, and the open source edition and the commercial one are separated by licence terms rather than by capability. ## The licence is custom, and the dates need reading carefully Two administrative facts deserve attention before anyone builds a plan on this repository. The first is the licence. The project is recorded with a custom licence that GitHub cannot classify, and the repository carries a LICENSE file, a PBS_License.txt and a COPYRIGHT file. Since the licensing was arranged precisely so the code could be released to the public sector while the commercial product continued under commercial terms, the terms are unlikely to be one of the short standard licences, and the file itself is the only thing to read. This is not a licensing question worth guessing about, and it is not legal advice either; it is a reason to read three files before you copy anything. The second is the maintenance picture. The releases listed are 2023, 2022 and 2020, and the last push to the repository was on 2026-04-10, so commits are landing in master while the tagged releases are older. Whether that reflects an active development branch, a maintenance phase, or a slow release cadence cannot be determined from the dates alone, and it is the question to put to the community forum before committing to a version. The project also says it is proven for over 20 years at thousands of sites, in both the private and the public sector. That is the vendor's claim rather than something the repository can demonstrate, but it does explain the shape of the thing: a scheduler with a plugin framework and a health check system is infrastructure that has to be trusted for a decade, not a component you swap out. ## Conclusion OpenPBS suits a site that already runs a PBS family scheduler, or a group that wants the scheduling and workload management machinery of a commercial product under an open source licence, and it is the wrong tool for a team that needs an off the shelf install with community support behind it. Verify first which licence applies to the code you are about to build, because the project uses a custom licence alongside PBS_License.txt and a COPYRIGHT file rather than a standard one, and check which release you are tracking, because the newest published release is v23.06.06 from 2023 while the last push to the repository was on 2026-04-10. ## FAQ ### What is OpenPBS and who maintains it? OpenPBS is the open source edition of the PBS Professional workload manager, a job scheduler and workload management system for HPC clusters, clouds and supercomputers. It became the new name for the PBS Professional Open Source Project in May 2020, with the same code under an open source licence. ### How do I install OpenPBS? The README does not give installation steps and points newcomers to www.openpbs.org. The repository carries an INSTALL file, an autogen.sh, an openpbs.spec and an openpbs.spec.in for RPM packaging, so a site that already builds from source produces its own package, and a site that does not should start with the project website. ### What can OpenPBS be extended with? It has a flexible plugin framework that the README describes as simplifying administration with enhanced visibility and extensibility, and the repository topics list hooks, plugins and provisioning. The overview also describes an automatic fail-over architecture with no single point of failure and a health check framework that monitors and automatically mitigates faults. ### What licence does OpenPBS use? A custom licence that GitHub cannot classify, with the terms in the LICENSE file, alongside PBS_License.txt and a COPYRIGHT file. The project states that Altair released the PBS Professional technology as OpenPBS under an open source licence for the public sector while continuing to offer PBS Professional commercially for the private sector. ### How is OpenPBS related to OpenHPC? The README states that OpenPBS is integrated in the OpenHPC software stack, whose mission is an integrated collection of HPC-centric components providing full-featured HPC software stacks. OpenHPC is a Linux Foundation Collaborative Project. ## Sources - [Issues](https://github.com/openpbs/openpbs/issues) - [openpbs/openpbs on GitHub](https://github.com/openpbs/openpbs) - [Project website](https://www.openpbs.org) - [README](https://github.com/openpbs/openpbs/blob/master/README.md) - [Releases](https://github.com/openpbs/openpbs/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openpbs-openpbs