This blog contains a discussion of website models for Open Source projects with Software as a Service (SAAS) element, and uses four real projects as examples. The website models described are:

• One Site: many things
  • Let’s get messy (the old phpList.com site)
• Two sites: many things
  • Super simple SaaS: complex self service (WordPress)
  • The same but different: follow the garden path (Piwik)
  • “Community? What community?” (SugarCRM)

Introduction

There is a large and ever growing number of Free Software projects which offer their software as a service (SaaS) to generate income, which in-turn funds further development of the project. This may be referred to as OpenSaaS.

Usually, there is a company behind the project, using SaaS as an aspect of it’s business model. A prevalent example is Automatic and wordpress.com. There is also often a community, NGO, charitable or non-profit aspect to the project too, for example wordpress.org.

OpenSaaS as a business model – more popular than ever

The OpenSAAS model is now happening often and early in the life of a project. Here is an extract from OS Trainings 2015 predictions:

“Gone are the days of open source projects launching without a business mode or with a non-profit organization at the head. Now open source projects almost always launch with a business plan and a revenue model.

New open source projects are betting that SaaS offers a much faster route to profitability than selling add-ons or services.”

There many critics of SaaS and perhaps by extension OpenSaaS. The quote below, from a talk description at Drupalcon Austin 2014, summarises my personal position well:

“OpenSaaS offers customers the best of both worlds– the innovation potential, freedom, and control of open source, plus the simplicity, quick time to deployment, and often lower up front cost of SaaS.”

ahoppin, outlandishjosh, robertDouglass & chrisyates

Money making and Open Source can be complex, but I would rather a project be genuinely Free Software with an OpenSaaS component, than have an Open Core model.

Building a picture: “it’s complicated”

The website of an Open Source project with a SaaS element is complex, it must do a lot. To explain this, let us first take a look at so websites which offer Software as a Service, but are not Open Source.

Two proprietary sites

When you look at traditional proprietary gratis (free of charge) service website such as twitter: things are very simple.

Below you can see the twitter home page. There is an elevator pitch (pink), log in (green), sign up (blue) and a small section for additional links, such as the corporate blog, jobs, terms etc (orange).

Next let us consider a traditional paid for proprietary downloadable software homepage: a little more complex perhaps, but still fairly simple. Below you can see the MS word home page: there is an elevator pitch (pink), call to action (CTA) of try or buy (green) and extra links (orange).

Even when we add in an extra level of complexity, such as a cross device synchronisation app or payment area (blue), these are very clearly second place to the try/buy CTA.

Two Open Source sites with no OpenSaaS element

Now, let us look at some traditional Open Source software sites, which critically do not provide SaaS.

As a Free Software project, you are likely to need to add in community elements. Below you can see the LibreOffice UK home page, which offers a gratis download, but no paid for services.

The top of the page has a large banner with the Download call to action (CTA) as a constant. The Download CTA has a rotating banner behind it with community related elevator pitches and a mix of photos, which include community (people) and software (pen for writing) related imagery.

Further down the page you can see the community related items (pink) and the software related items (blue) are along side each other, with a leaning towards towards more community items.

If LibreOffice were selling their software, the focus would probably be shifted the other way, towards the software rather than the community.

For example, the website of Collabora productivity Ltd (below) does not mention the community aspect of LibreOffice in an obvious way on its homepage, despite the company constituting a large part of the LibreOffice development community: instead it focuses on information about the products and services offered.

There is a small login area for customers, but this is a very different feel to super-focused SaaS sites like twitter, it is much more like the Microsoft Office site it its structure.

So, we have seen what a proprietary SaaS homepage might contain, and what an Open Source project site with no OpenSaaS element might contain. What is so different about an Open Source project which includes an OpenSaas element?

The OpenSaaS website: what is the problem?

An Open SaaS homepage could, in an ideally would include:

• The elevator pitch:
  • Which covers both the download and service aspects of the project or
  • Two elevator pitches, one for each aspect
• A log in and sign up for the service (may include try and buy).
  • Associated service CTA’s eg “buy now” or “create your account”
• A download CTA for the download aspect.
• A community elevator pitch and community CTA’s (donate, write documentation, make friends etc.
• Additional links to corporate blog, company jobs, service terms etc.
• Additional links to community resources such as community blog, sourcecode, forums and wiki
  • There may need to be additional log in areas for these
• Pricing of the service
• Features of both
  • Which may differ even if the code is identical: for example, you can’t usually use custom plugins on OpenSaas
  • Which may differ because the code actually differs: some projects use a “community version” model
• Some miraculous way to explain all facets of a Open-Source-paid-service-gratis-download-community-and-company-created-software to all visitors, who simply may not understand what Open Source or hosting mean.

I say “ideally would include” because this would be a “fair” website: the community and company, service and download would be equally represented without bias (indeed each has their own style and strengths). However, this in itself leads to complexity and even conflicts of interest, for example:

• How do you explain to a potential user that the should consider paying for something they could get free of charge?
• How to you make as much money as possible for the company, which is vital for development, without marginalising the community, who are also vital for development?

Let’s have a look at some projects who try and do this all in one site.

One website: many things?

Let’s get messy (the old phpList.com)

There are very few examples of this, if you see any, please leave a comment and I will discuss them.

The phpList website, before I was employed as Community Manager, was one example (hence my interest in the area). Below you can see a capture from the wayback machine.

In pink you see the service elements: there is a menu item “hosted” but no CTA. There are register and login button top right, which lack context.

The green items are related to the downloadble version. The main elevator pitch applies to download only, there are two menu items plus the demo, which pretty much conflicts with the service’s free trial account.

The orange items, for example features, apply to both – though serve neither perfectly.

The only community aspect is “contribute”, however, this leads to a wiki page which includes documentation and a small request to join in the project by helping with documentation and development. Additionally, the support menu item (green) leads to a page which tries to encourage people to support phpList rather than get support with phpList. The need to condense so many elements into one six link menu has created chaos.

We solved the community aspects to some extent by creating a community focused area on a subdomain, but more on that in the next post.

Two websites: many things, three examples.

Having examined the complexity of condensing an entire project, including a service element and community, into a single site, we now move on to looking at three “two site” or “sister site” models.

• Super simple SaaS: complex self service (WordPress)
• The same but different: follow the garden path (Piwik)
• “Community? What community?” (SugarCRM)

Super simple SaaS: complex self-service (WordPress)

The most notorious example of sister sites of this is wordpress.com and wordpress.org. WordPress.com is the higher ranked of the two, according to alexa.com and trafficestimate.com.

WordPress.com have a very simple service-only home page, a bit like twitter. You can Create Website or Login, there isn’t even very much in the way of features descriptions etc. There are no obvious outlinks to the .org site, though there are text links if you look.

It is interesting to see that the .com site benefits from the WordPRess brand as a whole, with the 23% of the internet claim which takes up 1/3 of the home page (shown below). That figure surely describes the total impact of .com and .org together, not .com alone?

The .org site, on the other hand, is extensive. There is a clear CTA to download, however, download is not the only reason to be there: there are themes, plugins and support etc.

The community becomes a sub-section of the .org site, with Get involved CTA in the main menu leading to the sub-domain make.wordpress.com, which keeps the same theme and header menu, but gives an additional menu in the grey make wordpress bar, which changes depending on the page you are on.

There are no obvious outlinks to wordpress.com, the Hosting page has small a text link. The theme and branding for both .org and .com are related, but not identical.

WordPress.com and WordPress.org, at the simplest level, have overlapping aims and branding, and offer the same source code. However, none of those things are identical: this means that they support each other, but do not complete for the same space.

Additionally, the “.org” and “.com” names have become brands in their own right: this conveniently:

• Removes the need for a word or phrase to describe the technical differences between them, eg hosted/cloud version v self-hosted/download version
• Removes the need for some kind of total brand name division which might threaten the cohesivenesses of the community as a whole (though this can work, for example with RedHat and Fedora).

Finally, we can put into context the scalability issues of a project site by looking at such a large project. As it stands the site structure of the .org site is quite deep by necessity: if WordPress tried to provide for the whole of the community including the SaaS clients from a single site, the structure would almost certainly become unworkable. There is a good discussion of deep versus flat site structures here.

The same but different: follow the garden path (Piwik)

Another interesting case is piwik.org and piwik.pro. Converse to WordPress, piwik.org (below) is vastly more popular than her commercial sister site piwik.pro.

The piwik.org website has a clever menu to allow a simple appearance to an expansive website. Otherwise, the site has a CTA driven style like WordPress.com, focusing on generating download’s and self-hosting users.

On the main menu there is a link to hosting (pink), which remains on the menu across the whole site. If you click this you get to a page describing Piwik cloud (below), which is a the SaaS component of piwik.pro’s services. At this point you are still on the piwik.org domain, but if you click either the CTA or the pricing text link below, you are taken to the piwik.pro domain.

You may not realise that you have moved domain, however, because the piwik.pro website is almost identical!

I think this is an interesting situation, though I don’t completely understand the logic. Like WordPress, a lot of brand strength is kept between the two sides of the project, however, I am not sure what piwik.pro have to gain by taking this as far as the twin-sisters-style sites – one could argue they don’t gain, as their site remains significantly less popular.

Interestingly, the sites have not always been so similar, in the wayback machine you can see they were very different in theme and logo until January 2014, when they starting to inch towards each other, finally becoming two of a kind in late 2014.

Finally, to reach piwik.pro, the visitor must have some understanding of what “hosting” means, and that the download software is not ready-hosted: there is a lot of room for confusion there.

“Community? What community?” (SugarCRM)

In my view, it is possible to use your website as a tool of destruction and or disrespect towards your community: there are numerous examples of this (sadly).

Micro-disclaimer

I do accept this can be accidental, or a result of poor planning and the lack of established best-practice/guidance (which I why I have written this blog series). Certainly, I can imagine aspects of my first attempt at a community site could have been seen as deliberately making life hard for the phpList community: where as I know that this was 100% not the intention. Therefore I don’t want to name-and-shame any particular projects: however, SugarCRM is a big and ugly enough target that I hopefully won’t be offending anyone personally.

SugarCRM, which was/is Open Source, stopped releasing it’s Open Source “community version” in 2013. Their website actively places obstacles between the visitor and the community version download. The only links to it are at the very bottom of the website.

The Download Community Edition link takes you to a second page:

where the visitor must choose the blue link (very matrix). This then takes the visitor to a third page, where they must put in their details including a phone number:

Finally, this the download can begin… from SourceForge! (ie: you need not have given them your details at all.)

There are some community forums, also accessible from the footer, which have the meta title “SugarCRM® Community” – I class this as the second site for the purposes of this example. The language there seems intentionally banal, describing the forums as “a place to share and connect with other people that are passionate about the same things you are.”

(Insert snarky comment: Great, I can meet other people that like knitting/beer/cake!)

Indeed, that deliberately vague description which deliberately (surely) excludes any keywords related to SugarCRM or even CRM in general, is the meta description for the entire sub-domain. Bearing in mind search engines will/may treat a sub domain as a unique website, this feels like SEO as a form of self-destruction: it may as well be saying to search engine users “please don’t visit my site, it has no specific purpose!”.

To summarise, sugrarcrm.com is a loveless place: I see nothing of Open Source or Free Culture in it. What really concerns me is that, perhaps, some of the smaller Open Source projects with equally unhealthy community site offerings look at SugarCRM and think “this is how you make money in OpenSource – you use the community to build your product then you screw them over.”

Why we need to rock the site right.

One good way combat bad OpenSAAS etiquette is to document the websites, branding and business models of those projects that have a great community and make money at the same time, then explain how to build and transition to websites/branding/models like those. This is a big undertaking, and I can’t do it all myself.

My next blog, however, provides very detailed information on How to restructure complex Open Source and OpenSaaS project site into .com and .org sister sites.