In 2013 a small team of engineers at realestate.com.au created a tool to solve the problems they were facing when it came to testing and releasing a nascent style of architecture called microservices. Beth joined this team a few months later and made some key contributions, including the invention of the Pact Broker as the most influential. When it became apparent that this was a more general problem, with permission Ron open sourced the library. Its name was Pact. In the following years, a global community of maintainers and users was established and grew rapidly, making Pact the de-facto tool for contract testing with distributed systems. In 2019, Beth, Ron and myself launched Pactflow to enable enterprises to adopt contract testing more quickly, and at scale.
Open source has always been at the heart of what we do and will continue to be. Here’s what the open source community means to us, and what we're giving back to it.
Why create a company around open source software?
We ❤️ open source. We created Pactflow because we wanted to create a sustainable avenue to work on open source projects, and solve big problems that benefit a global developer community. Instead of the train rides, late nights and weekends where most of our contributions previously originated, this would be our day job.
This need for sustainability was underscored as we all became parents, and realised that our free time was about to be drastically cut back. We didn't want to have to choose between our "real" family, and the thousands of adopted members of the global Pact family.
We're committed to making Pact a thriving project, growing our fantastic community and solving bigger and better problems, and have designed Pactflow in such a way that its success is interlinked with the success of Pact, creating a virtuous cycle that ensures mutually beneficial outcomes.
When we originally set out on our personal goals of working full time on Pact, we looked into various business models that could sustain us. I won't go into it all here (there is much out there about this topic), but we felt that the best sustainable pathway was the creation of a commercial entity that was penned to the success of open source. Of course, doing this meant that we also needed to make the company itself profitable which inevitably leads to working on or doing other things, that isn't open source development - this is a constant balancing act.
We also felt that having a commercial entity behind Pact, if you will, will be a positive signal to the market and to those customers and engineers wanting to adopt contract testing with Pact. That signal being that the project is alive and well, and that there is a commercial entity that will be there to see it succeed, and it won't have to rely solely on the generous but sporadic volunteering that many open source projects suffer from.
The taboo of 💰 and sales
This is the other tightrope that we walk out on most days - Pactflow is a commercial product, and not everyone in the community will appreciate this fact and how it manifests itself in the eye of the public. As developers, we hate blatant sales and marketing tactics, but we aren't ashamed to recommend Pactflow where we see a good customer fit. These aren't in conflict: we see selling as an extension to solving a problem, and more philosophically, we need to normalise the fact that sustainable open source requires funding avenues.
It shouldn't be taboo for an engineer with strong comprehension of the context to recommend a product to another engineer.
So whilst there is a strong aversion to sales and being sold to, there is often an equally strongly held expectation that a bug must be fixed or feature implemented ASAP even if the end-user is not a paying customer. This is a broken asymmetry.
Approached with curiosity, honesty, transparency, humility and trust built through hard-fought reputations forged in a rapidly evolving community, a Pactflow team member may suggest a community member consider paying a subscription fee to support the work we do. We think this is fair.
🔨 How does Pactflow contribute to OSS?
Whilst a scrupulous look at our commit history would show that we still contribute "out of hours", it's clear that we are beginning to succeed with making things more sustainable.
As a policy, we commit at least 10% of our engineering time toward open source development.
2023 UPDATE: Whilst the above policy is still in effect, in practice the commitment was lower than was needed to sustain the project and the % itself is kind of irrelevant. See our smartbear supported initiative for more on how this topic has evolved.
Our mission is to enable organisations to get more value from Pact and contract testing quickly and at scale.
What follows here is an attempt to show how we think about things, and to show some evidence of that at work. It's not about patting ourselves on the back (although we won't turn down a hug if offered), but offering some transparency in our approach.
The founders of Pactflow maintain significant control over the direction of Pact, and we intend to increase our leadership involvement going forward. Being at the intersection of paying customers, the community and contributors, combined with analytics and insights amassed from aggregated data across thousands of Pactflow accounts, we truly are in a privileged position to help drive its future.
Currently, we have core maintainers for the following projects in the ecosystem and are able to have significant influence on the direction of the project:
- Ruby (the original Pact!)
- This is also used as the legacy core engine for PHP, Python and other languages
- The Pact Specification (where our interop standards are defined)
- Pact Broker
- JVM (Java/Kotlin/Android etc.)
- JS
- Go
- Python
- Rust
- Including the client language, core engine and plugin framework
⚖️ How do we decide what goes into Pact vs Pactflow?
The general rule of thumb is that if the feature helps organisations do contract testing at scale, it goes into Pactflow (Federated Auth, Teams, Roles and Permissions are good examples of this). If it's a feature that helps developers on the ground, it goes in to Pact (Pending/WIP Pacts are good examples of this).
We won't always get it right, either commercially or from the perspective of the community. The good thing is, most of these decisions aren't one way doors - we have the opportunity to reverse them if we believe we got them wrong.
For clarity. What we don't want is a "barely useable" open source tool, and a functional commercial one where you must pay money to use it "for real". That's not open source, that's the equivalent of putting a watermark on any image produced through an unlicensed graphics editor. Anyone should be able to do contract testing with the free and open source tools without qualification.
Without picking on the authors of autospotting.org (I'll work with the charitable interpretation of it being a language barrier), this is not a commercial strategy we want to support:
Not everyone will give us money - and that's both OK and expected. Our strategy is to make Pact the best tool it can be, and capture a subset of the Pact user community who value the features we've built to help them do contract-testing quickly and at scale.
Features launched🚀
Since we started Pactflow, we have launched a number of key features into the open source ecosystem including:
- A complete overhaul of the docs
- Pending and WIP Pacts
- First class support for Branches, Environments and Deployments
- XML Support in Java, Rust and JS
- RFC and implementation of the V4 Specification
- RFC and implementation of the Pact Plugin Framework
- A gRPC and Protobuf plugin
- v3 and v4 spec support in JS, Go and JVM
- Addition of C++ as a supported language
- A Pact Terrform client
- ...and hundreds of other feature requests across the ecosystem
Growth, diversity and a thriving ecosystem 🌳
Whilst we've discussed the benefits of the involvement of a commercial entity, we also believe an open source ecosystem thrives with diversity to ensure the needs of the community at large are served. Part of it is accountability, but like a workplace, diverse people, opinions and experiences create better products and outcomes. This should extend to people who don't work at Pactflow, because we will have our biases.
For this reason, we’re currently recruiting core maintainers across several of our languages to ensure this diversity. Pact adoption is growing rapidly year on year (see the JS project download chart above), and contributing to Pact has benefited our careers in ways we never expected. We'd love to be able to replicate and create new and unique experiences for the next generation of maintainers.
If you’d like to be part of the future of Pact, grow your developer profile and solve fun problems we’d love to take you on that journey with us. Plus, we’ll also send you some sweet swag 🎁. Let us know, and we'll setup a call.
