LibrePower · Port open source to IBM Power
Software Porting

Port open source to IBM Power.

The ppc64le builds, AIX native ports and IBM i PASE work that consolidations from x86 and POWER8 to POWER11 usually get stuck on.

Where ports stall
POWER8/9/10/11 ppc64le · AIX · IBM i (PASE) Worldwide
Where ports stall

The hardware part is easy. The software is where a Power migration sits half-done for two years.

01

Upstream ships amd64 only

Your dependency releases x86 binaries and x86 container images. ppc64le lives in a # TODO somewhere. Someone has to build it — and keep building it every release.

02

Native extensions and assembler

C extensions, JIT paths and SIMD written against x86 either fail to compile or return wrong results on ppc64le. Cross-compiling won't catch this.

03

Transitive dependencies without a port

Your app builds. Its dependency's dependency doesn't. It becomes a directed acyclic graph, and someone has to walk it, patch it, and upstream what's accepted.

04

Pipelines that only speak x86

Runners, base images, cache layers, signing, artefact stores — every step assumes amd64. Multi-arch is a pipeline rewrite where ppc64le is first-class.

05

No owner past go-live

The port works on cutover day. Six months later a CVE, an upstream bump, a new transitive dep. Without ownership, the port rots and the estate slides back to x86.

The three tracks

AIX, IBM i and Linux on Power.

Three different problems, three separate tracks. Native ports on AIX, PASE runtimes on IBM i, containers on Linux ppc64le.

AIX 7.1 / 7.2 / 7.3

AIX native ports

Native compilation with IBM Open XL C/C++ (LLVM-based) or GCC where it makes sense. No containers — AIX is not a Linux.

  • Dependencies packaged as installp or RPM
  • Functional and operational validation on real Power
  • GPG-signed artefacts, SBOM per package
IBM i 7.3 / 7.4 / 7.5

IBM i (PASE)

PASE for anything open source — Python, Node, Java, PostgreSQL. Then the interesting work: the boundary with ILE and Db2 for i.

  • Runtimes packaged in the native IBM i repo
  • ILE / Db2 for i integration where it matters
  • No containers — modernize natively via PASE
RHEL · SLES · Ubuntu ppc64le

Linux on Power

Where containers do make sense. RPM and DEB packages, OCI images, multi-arch manifests so the same tag pulls the right binary on x86 and Power.

  • Native ppc64le pipelines — not cross-compiled
  • OCI multi-arch for OpenShift and Kubernetes on Power
  • Upstream contributions where accepted
What ships

A reproducible port your team owns.

Source patches

Upstreamed where accepted, kept as a private layer where not.

Build pipelines

Reproducible on your side, target ppc64le, AIX and PASE directly.

Signed packages

.rpm, .deb, installp — or OCI images with multi-arch manifests.

SBOM per artefact

Software Bill of Materials in CycloneDX, ready for compliance.

Test evidence

Upstream test suite plus your integration tests, on real Power.

Runbooks

Deploy, upgrade and rollback — written so someone else can execute.

Post-launch ownership

Optional: CVE tracking, upstream bumps and dependency changes so the port doesn't rot.

The sequence

Prove the hardest workload first.

Migrations that ship on time pilot the ugly workload — the one where the ISV shrugged and the maintainer stopped answering.

01

Map

Inventory apps, versions, dependencies, runtimes and integrations. No opinions yet.

02

Classify

Each app gets a route: rehost / rebuild / port / containerise / replace / retain. A wish is not a route.

03

Prove

Pilot the highest-risk workload first — on real Power hardware, with real data. If that ports, everything else is a variation.

04

Industrialise

Turn the reference port into pipelines, standards and quality gates the rest of the estate reuses.

05

Operate

Waves, cutover and lifecycle ownership past go-live. Someone tracks CVEs and upstream bumps — or the port rots.

How pricing works

Priced per project. Scoped after assessment.

No public rate card — two ports of the same package on the same runtime can differ by 10× depending on the shape of the upstream. What's fixed is how we get to the quote.

Step 1 · Readiness assessment

Two weeks of engineering. Fixed fee. Written deliverable: inventory, classification per app (rehost / rebuild / port / containerise / replace / retain), risk matrix and a scoped plan you can share with your customer or your board.

Step 2 · Scoped quote

After the assessment, each port is quoted as a fixed-scope engagement based on real findings. Not an hourly bucket, not a T&M open tap.

What shapes the quote

Number of applicationsSingle package vs a dependency graph of 40.
Target runtimeLinux ppc64le is faster than AIX native, which is faster than IBM i PASE integrations.
Upstream stateCooperative maintainer vs abandoned repo vs actively hostile to non-x86.
Native / assembler codePure Python is minutes. Rust with x86 intrinsics is weeks.
Transitive graph depthEvery unported transitive dep multiplies the work.
Post-launch ownershipOne-shot port vs continuous CVE tracking and upstream bumps.

No free discovery calls. The assessment is the discovery, and its deliverable stands on its own even if you never contract the port.

FAQ

Questions we get asked.

Quoted per project, not from a public rate card. The readiness assessment is a fixed fee of two weeks with a written deliverable. The port itself is scoped after that. Cost drivers: number of applications, target runtime (AIX / IBM i PASE / Linux ppc64le), upstream cooperation, native code and whether you want post-launch ownership.
A well-behaved single package on Linux ppc64le: days to a few weeks. Packages with native extensions, x86 intrinsics or a wide transitive dependency graph: longer. AIX native and IBM i PASE work run longer than pure Linux. The assessment gives you a written timeline before any port work starts.
Yes — that is the reason this service exists. We patch the build system, resolve or replace transitive dependencies, contribute upstream where accepted, and maintain the port under engagement so it doesn't rot.
Real hardware. POWER8, POWER9 and POWER10 in the pipeline. Cross-compiling is a smell test, not a delivery method — it misses endianness bugs, native extension issues and PASE-specific runtime behaviour that only shows up under real execution.
No. Containers are a Linux construct. On AIX and IBM i we modernize natively. Containerization applies to Linux ppc64le workloads, which then talk to your AIX or IBM i systems over the network like any other service.
Yes. Partner-led engagements where the customer relationship stays with the partner and we produce the ports, packages, containers, evidence and handover documentation.
Fine. The assessment scales down: shorter, lower fee, focused inventory. The important part is the written classification and quote — even a single package benefits from that discipline because it makes the maintenance question explicit from day one.
Start with an assessment

Get a scoped plan before quoting.

Two weeks of engineering, fixed fee, written deliverable. If you already have the shape in your head, we get to the port faster.

Request an assessment Back to services

or write to hello@librepower.org