Open Social: a SaaS solution for custom communities at scale

14 October, 2020

Adriaan Odendaal

Content writer

In 2016, Open Social announced our partnership with Platform.sh. This partnership has enabled us to create a simple and secure way to deploy new online community platforms for our clients (and keep those communities running without a hitch!).

It’s possible that even if you’re an Open Social client, you may not be aware of the fact that your community is actually running on Platform.sh. On the other hand, you may be a Platform.sh user already, but weren’t aware that there were businesses built to a large extent on top of their API.

Either way, our collaboration with Platform.sh has enabled us to maintain thousands of community sites, and we thought you might be interested in how it all works.

What is Open Social?

For those who are unfamiliar, Open Social is a Software-as-a-Service (SaaS) online community solution. This means that we set up community platforms for clients, including company intranets and knowledge bases for governmental organizations, as well as e-learning platforms for NGOs and others. You can very quickly receive an out-of-the-box online community, and then as soon as it’s deployed, you can customize the site in a number of ways to suit your organization—from adding branding and selecting a color palette to uploading custom content and changing its layout.

But how does Open Social work?

SaaS products like Open Social can get tricky: how you choose to deliver a piece of software to clients can often introduce limitations on what the software can (and can’t) do when they finally get it.

You can choose to provide clients with their own isolated instance, and that comes with a lot of benefits. Their sites can be customized completely, from their look and features to scaling to meet traffic demands, but that approach does have downsides. If you're successful enough to set up hundreds of clients with their own instances, what’s the best way to ensure regular updates and consistent security across all of them? You’d need to build tooling to manage it, and that investment could run up the already considerable operating costs of the instances themselves.

Alternatively, you could very well decide on a more shared approach. In this case, individual clients really only have a slice of the whole product in the cloud, rather than their own instance. This can be helpful in initializing what they see and keeping every client up to date very easily, since everyone’s sharing the same data. But without true isolation, the software they get is at least in some way dependent on that shared data, as well as the health and security of the larger ecosystem. And an individual client’s site becomes that much more difficult to scale and customize.

Trying to get the best of these options without their respective setbacks is what led to our current model using Platform.sh. At the most basic level, each community on Open Social is a Drupal site, and each site’s code exists on its own Platform.sh project. To manage this model across all of our clients’ communities, we built a tool called Multiverse. Multiverse wraps around and leverages the Platform.sh public API to manage both individual and larger groups of projects, keeping all of our communities updating regularly in the background.

With this model of one project per community, with a larger API at our disposal, we do get the best parts of those two options for offering a SaaS product. If you sign up for Open Social, you’ll get a Platform.sh project that’s completely isolated from anything else. No other community site affects yours, and your site can be scaled up, scaled down, and customized however you need it to be, at any time. Retaining this ability to customize is essential for the very idea of a community. We can then initialize and create new communities quickly from a common template using the Platform.sh API, and then continue updating the whole fleet—that is, all of the communities we oversee—in the background from then on.

Multiverse: focus on building communities, not platforms

With the development of Multiverse, we’ve automated the entire process of initializing and deploying sites for individual communities. “Multiverse controls just about everything,” says Open Social Senior Developer Ronald te Brake. “Multiverse receives the site and domain name from the customer success manager and then talks to Platform.sh using the API. It can say, ‘Okay, I need a new environment in the German Region, the European Region, or the US region.’ And then Platform.sh will start creating that environment. And once that’s done, Platform.sh will send a signal to Multiverse, so we know the site has been created. Multiverse can also say, for example, ‘I want the site name to change,’ so it can also update the community using the API.”

All of these things can be done through the Platform.sh API, which enables our team to manage nearly every aspect of an account and the communities hosted with us. te Brake shares, “It’s really good at opening up all the necessary configurations for us to create, manage, and maintain websites. The API allows you to abstract it a step up, so you can make changes to multiple projects at the same time.”

Instead of relying solely on Platform.sh’s management console to manage individual projects, Multiverse provides the interface to all communities, opening up considerable fleet management capabilities for us.

Multiple online communities are hosted on Platform.sh and managed by Open Social through Multiverse.

Multiverse works because of our consistent model shared by every community on Open Social. Since every community is a Drupal site on a Platform.sh project, we can very easily initialize new communities with a well-tested template and extensions through Multiverse. Each community will want a specific domain, which just becomes another endpoint called through Multiverse. “You can do everything you need to through the dashboard as well, te Brake explains. "But it's more just manual labor. The end-goal of Multiverse is to make sure we can just about automate everything."

So what does the customer get from Open Social working with a tool like Multiverse sitting on top of Platform.sh—besides the trade-off between isolation and being a part of our large-scale community monitoring and security practices?

FIrst of all, Multiverse enables Open Social to anticipate the external integrations communities commonly need, making them part of the initialization and maintenance process tied to their accounts. Stripe credentials get added to the accounts and the Multiverse dashboard, so everything that our developers and account managers need to know about one community is totally available.

As a result, Open Social clients don’t have to ever worry about hosting. Client site managers don’t have to log in to the hosting platform themselves. “It’s only developers logging in,” says te Brake, “And that’s why we’d rather have better APIs and a better developer experience.” This is exactly what Open Social gets from Platform.sh: a trusted partner that understands the needs of developers. “The fact that Platform.sh opens up the API means that it gives us a lot of opportunities that aren’t directly visible to customers. Users don’t notice anything in the entire process because there’s a partner that does this for us and takes away any potential problems,” says te Brake.

Another interesting side effect of this relationship is the kinds of communities we can initialize, including some that open up new opportunities for both Open Social and our clients. Since each community is a Drupal site, it’s possible through Multiverse to set clients up with a multisite solution: where a client’s project is actually multiple Drupal installations sharing the same codebase.

This solution is very useful for large NGOs that regularly run different projects or campaigns, both internally and externally, and need a standardized way to bring stakeholders together online. If a client needs a number of separate (but interoperable) communities, Open Social can create a custom community template that lets us nearly instantly deploy a new community and make it live. Ronald te Brake explains, “We have a template—a shared set of features that has been combined—and you can use that to easily install a new environment with the same configurations.”

API helps deliver a seamless customer experience

In the end, the Platform.sh API removed a lot of the limitations we would have encountered early when designing Open Social. It wasn’t as necessary for us to weigh the trade-offs between developing a single tenant (one installation per client) or multitenant (shared resources between all clients) model for our product. Instead, we could get the best of both models by providing isolated instances for each of our clients that are initialized and managed as a part of a larger ecosystem of communities with Multiverse. This approach enables us to provide secure and dependable sites for our clients—all while allowing them to customize those communities as they grow and evolve.