As any technologist is well aware, some of the most basic decisions have the potential to make or break your end-product. One of the most fundamental of those is the choice to build, buy, or open source your technology. If there was an off-the-shelf option we could buy that matched our central requirements, we wouldn’t have decided to build Hum! That left us with two choices around which to base the core of our platform: Build or open source.
Tech gurus often debate open source versus closed source for novel technology development. Each has its own distinct benefits and drawbacks. There is not a one-size-fits-all approach. While there are advantages to utilizing open source, there are also advantages to building proprietary software that is adapted specifically to your needs.
What Is Open Source?
Open source software is built using publicly available source code that is licensed to be used for free. With the ability to edit, share, and distribute data, open source is exactly what it sounds like – openly available to be accessed, edited, and modified by all.
Some examples of open source programs are WordPress, Android, Linux, and Firefox Browser.
The Pros & Cons of Open Source
When determining the technical requirements of your next software build, here are a few things to keep in mind. While there are many benefits to starting with open source, there are also a few drawbacks:
Pros of Open Source:
- Flexible and customizable
- Secure, stable code
- Freedom to share, edit, and distribute
- Easily modifiable and shareable
- Community-based recognition (just as doctors share with other doctors through scholarly articles - developers can share their own work amongst other software professionals too)
Cons of Open Source:
- Vulnerable to malicious misuse (due to the multitude of users that have access to the code)
- Not always considered user-friendly
- Not equipped with extensive support
- Often advertised as free, but there are start-up costs, installation, data importation, maintenance, etc.
- Steep compliance requirements
As we built Hum, we considered all of this. As we started to explore associaton needs and pain points, it quickly became apparent that Hum needed to be a completely novel software product.
How We Started Building Hum
When we first started to work on Hum, we knew we were solving a real problem for associations, but we weren't exactly sure what the solution needed to look like. Several associations had proven the need and the potential power of an Association Intelligence Platform… but the product itself didn't exist. These associations and their enterprising tech teams had solved the problem for themselves by installing a CDP, stitching together all of their platforms, and implementing countless integrations and customizations. So that was one option… but then we'd be integration specialists and service providers. We really wanted to instead develop a scalable solution by building a SaaS platform - Something that wouldn't be prohibitively expensive for a mid-size association to implement.
We realized pretty quickly that if we were going to go the SaaS route, a CDP would need to be the foundation of what we were building. As we researched CDPs, we learned that they are hugely varied, and they're good at different things. As David Raab, CEO of the CDP Institute, says:
They all meet the core capability, or they wouldn't be a CDP, but some are better even at the core stuff than others. So you really have to understand a fair amount of specificity.
We ultimately determined that we would need to build our own CDP in order to meet our business needs and more easily implement additional services around the product in the future.
Open Source + The Hum Platform
Building our own CDP seemed like an unusual step at first – and a pretty ambitious chunk of development to bite off. However, our tech team was confident that this was the right choice.
First, they narrowed down our options and determined that there was only one viable open-source candidate: Unomi. Then, we evaluated Unomi against the stated product requirements. This sounds more straightforward than it really was because, as a start-up, our product requirements were not exactly crystal-clear.
Going into the evaluation, we recognized that there's an inherent value in building your own system when you have specific product features and applications in mind, rather than spending time setting up, learning, and customizing an existing 3rd-party system to your requirements. But we also didn't want to recreate the wheel if there was a perfectly good wheel available to use for free.
Why We Decided on a Custom Build
Here's why we ultimately decided that we needed to build our own CDP to form the core of the Hum Association Intelligence Platform:
We wanted content to be a first-class citizen in our CDP.
One of the most important features of Hum is the ability to make personalized content recommendations delivered across multiple platforms. We couldn't do that with Unomi. While it would have been possible to build the content recommendations as a separate system, there was a good reason to instead build this system as part of the CDP. The two systems share a lot of data, so it's important for them to be connected.
- The CDP must be "content-aware" in order to properly evaluate users' interests.
- The recommendation system must be able to read all users' interest data.
- The recommendation system must be able to read the customer's history on visited and consumed content.
- The recommendation system must be aware of the ratings of every content piece in its inventory, and this data must also be collected by and stored in the CDP.
Most importantly - we needed all of the above to happen with minimal delay.
We wanted to have the ability to retrospectively process (or re-process) events within a specific context.
This allows us to have a much better understanding of what events actually mean because we're able to combine events in order to have enough context to interpret them.
For example, consider a "browser tab closed" event. By itself, this event is neutral. But within context it might mean disinterest, or it could mean a misclick, or it could just mean that a page was opened twice, so someone closed the extra tab.
For a more complex example, consider the implementation of a "degrading interest" system. This would be used to retrospectively re-process events in order to gradually nullify collected interest values within the user's profile as time goes by, (if we find that they are no longer clicking on or reading the same kinds of content).
We wanted to be able to adjust segments dynamically.
Segments that can either lose or acquire user profiles, even when there has been no change on the actual user profiles themselves. This is handy for targeting purposes, especilly for marketing campaigns.
For example, a segment might be created to include "users that did X during the last N days" or "top N% of users by revenue." Audience segmentation is one of the core power areas of the Hum platform. It is important that our platform has this kind of flexibility so that users can create useful audience segments across a variety of dimensions.
We wanted to have the ability to make a direct ElasticSearch query through the CDP API.
Our tech team determined that it would make the most sense to allow proxy ElasticSearch requests to facilitate specific queries which require wide querying capabilities. That meant that having a controlling layer on top of ElasticSearch would be beneficial, as opposed to making the requests to ElasticSearch directly.
Most of these features could have been accomplished via the extensions system in Unomi, but given that we did not have a clear and comprehensive list of all potential future requirements, we had concerns about starting down this path with Unomi, possibly needing to change the source code in the future. We did, however, borrow a few ideas from the Unomi CDP, validating some of our own ideas by way of the Unomi design.
What's Next for Hum
We're very happy with the decisions we made.
A lot of research, experimentation, and development time has resulted in a powerful foundation for our Association Intelligence Platform.
Our custom foundation provides the flexibility to continue to improve the product as we better understand the unique needs of associations. Our approach to product strategy (and really all operations) is to learn and improve with a nimble, experimental mentality. Our early customers can attest to our excitement about getting their feedback as we build Hum into a transformational product for associations.
If you're interested in learning more about the nuts and bolts of the Hum product, check out this post on Association Intelligence Platforms and see how Hum's CDP works. If you like what you see, reach out and schedule a more in-depth platform tour. We will address your specific questions and concerns about how Hum might help transform your organization's approach to digital content and experiences.