How do systems integrators make money on DPGs?

"If the software's free, where's the money?"

Systems integrators ask me that almost as often as governments do. Plenty of them still aren't convinced there's a real business here. The scale of deployments, and the growing crowd of firms working in this space, say otherwise.

The short answer: systems integrators make money on digital public goods mainly through implementation and annual maintenance contracts (AMCs). They get paid to configure, integrate, migrate data, train staff, host and support the system, not for the software licence. The firms that do best invest in accreditation, training and contributing back to the DPG community, and pair local presence with delivery depth.

Key facts:

• Revenue comes from implementation and AMCs, not licences
• Most DPGs run accreditation or partner programmes for implementers
• Governments tend to favour SIs with experience in their region
• Tier 1 consultancies and small local firms both win DPG work

Where does the revenue come from?

The AMC is the underrated one. Implementation wins get the headlines. The long-term support relationship is what turns a project into a business. See what happens after go-live.

Who's winning DPG work?

What I find encouraging is the range.

At one end, Tier 1 firms like Deloitte and EY take on DPG implementations. At the other, small regional tech companies in frontier markets train themselves up, get accredited and win projects in their own countries.

That range isn't an accident. Open source means anyone can learn the product. Accreditation means anyone serious can prove it.

What makes a DPG tender winnable?

From what I've seen, governments look for three things:

1. Regional experience. A track record in the country or region counts for a lot.
2. Local presence. If you don't have regional experience, partnering with a local provider, or bidding as a consortium, can give you a real edge.
3. Accreditation. Most DPGs run accreditation programmes. Being accredited on the product de-risks the implementation from a governance point of view, and evaluators notice.

If you're a global firm with no footprint in the region, the consortium route is usually your fastest way in.

The tender problem

Here's a frustration I share with a lot of SIs.

Tenders are often written by people who don't yet know what they don't know. Some are generic templates. Some are either too low-level or too specific in odd places. That mismatch bleeds into evaluation, so the scoring doesn't always match the capability actually needed.

My advice to SIs: engage early. Pre-tender clarification rounds and conversations with funders are where you can help shape requirements that make sense. By the time the tender is published, it's too late to fix. See how DPI is funded.

Why the contributors win

This is the part SIs tend to underestimate.

DPGs lean on their ecosystems. The partners who invest in capacity building, train their people properly and contribute back to the community, whether that's code, documentation or feedback, are the ones who do really well commercially.

It's not charity. Contributors know the product better, get noticed by the DPG team, and get recommended when a funder or government asks "who can do this?"

My take: in this market, visibility inside the community is worth more than any sales team.

Is it worth getting into DPGs?

I'm obviously biased: I think it's one of the best opportunities in government tech right now. But be realistic about the pace.

The slow part: government contracts, accreditation and winning deals all take time. Your first win can take a while.

The fast part: once you're in, delivery is much quicker than building from scratch. You start from a tested product, not a blank page. That speed to market on the back of DPI and DPGs simply doesn't exist when you build bespoke.

If you're an SI thinking about it, start with one DPG that fits your markets, get accredited, find a first project, even a small pilot, and build from there.