There has been a lot of ink written about software models and why/when it makes sense to use open-source software (OSS); there was recently an interesting article about that specific topic. The short story is that such decision is based on many different factors, including the available options (OSS and non OSS), engineering organization, short term/long term choices, company DNA, … In this post, i would like to focus on our project specifically by asking two questions, one addressed to folks looking for billing and payment solutions and one to the Kill Bill team (note that i am both asking the questions and answering them for all parties, which is quite convenient…)
Fictitious Journalist: “So, you are looking for billing and payment solutions, what are your choices, why Kill Bill?”
In the world of billing and payments, companies are left with 3 main options (all of them with their pros/cons):
1. SAAS model
This is often presented as a turn key option that will solve all your problems so you can focus on your IP and not be distracted by things that are irrelevant to your business: This statement is true in the sense that pretty much any developer using (pretty much any language of his choice) could quickly integrate with a SAAS business and start processing subscriptions, or making payments through a gateway. However, it is also misleading for the following reasons:
- Each business will need its special business logic and so simply using the raw apis from the SAAS will not be enough; often there is a need for another system in front of that SAAS (to implement missing features, work around bugs, …) and this can quickly become a source of headaches (based on our past experience).
- In the SAAS business, all the financial data now lives in the SAAS, and will need to be ETLed in some sort to satisfies business analytics requirements, create financial reports, … Often such SAAS solutions provide metrics but in this data driven age, most companies need to have access to data directly to slice and dice as needed.
- Testing is often provided through a sandbox with all the gotcha: Which software version does it run? Is it stable?, Can you reset its state? Can it be used for load testing? Can you analyze the test data? Can you run multiple test suite in parallel? …
- Complementary functions such as tax calculations, fraud detection, chargeback management are also often performed by the SAAS solution leaving no room to explore other (maybe better?) options.
2. Write your own
This is where we started. Well, i can’t discourage you to go down that route, but be prepared for a long journey: We started 5 years ago, and are still actively writing code. Now, our goal is to provide a generic platform to address billing use cases and solve payment integrations, and as such, this is more ambitious than solving one specific company’s needs (assuming those needs are clear in the first place, and assuming they don’t change with time).
3. Use OSS solution (e.g Kill Bill)
I would certainly not claim this is the path that should be chosen: If your goal is to look for a short term solution, if you have very limited engineering resources, and if you are ready to sacrifice features, flexibility and just live with what exists out there, then move on.
For one thing, Kill Bill does not solve (yet) all the billing and payments problem in the world (working on it…), and the effort required to understand the system, and build on top of it in order to address one’s custom needs is non trivial. For some, the learning curve is steep, but past that stage, it will put you in a position of control (you own your data, the code is available, bugs are addressed quickly, you can test easily, you can extend easily).
Fictitious Journalist: “So Kill Bill team, how is OSS working for you ?”
I would lie to you if i were to say things are easy… Initially you start from nothing, then you build code but nobody uses it, then you get people using it so you have to answer lots of questions, fix bugs, write more code, write documentation… Sometimes people are grateful, sometimes not so much. This is true for all OSS projects, nothing specific to our project.
What’s specific to our use case is that we offer a billing and payment platform and not a small library that could be tried and discarded easily in the eventuality it does not work. Companies know that choosing their billing and payment infrastructure is not a light choice because the whole company depends on that system and so moving away is always a challenge. Then, after such choice has been made, there is also a commitment from our side to make sure things work as expected and leave such companies in the best possible position.
After 5 years, we are entering deeper in the adoption phase, we know of at least 10 companies using our system in production (all in a very different way), and we started to receive more and more external contributions:
- One of the company using the system (not yet public) has partnered with a consulting company from Argentina to help develop missing features and fix issues. We have had a great experience working with their engineers, they have closed 67 issues , implemented the hierarchical account feature, and recently created a Kill Bill dwolla integration.
- We also had multiple companies open sourcing their plugins (e.g braintree plugin) or client libraries (e.g .NET client library. Recently, Womply just decided to open source their implementation of Authorize.Net to satisfy the needs of other users.
- Of course, Groupon who hired the core team, remains by far the best contributor to build their global payment platform
We are thankful to all users, contributors and always ready for feedbacks or ideas to improve the platform.
