I'm curious whether the business model is truly the problem. While I'm sure LocomotiveCMS is a nice product, it's operating in a very crowded space with numerous and established open-source, proprietary, and hosted solutions. From the way it's described on your website, it doesn't seem particularly specialized and thus highly valuable to a niche of the marketplace.
I wonder what would happen if a) you focused v3 on having features that specifically made it awesome for dentists with HIPPA compliance issues. Or cross-eyed investment bankers. Or someone with deep pockets and an unusual, unmet need and b) shifted the value of open-source from shared development costs to risk-avoidance. Namely: customers have an escape hatch if you cease development because they can update the source, export data into novel data formats, etc.
This. It feels like they're trying to solve technology issues instead of real world market issues.
If I'm a WordPress guy who needs to get multi-site going, then I'm going to figure it out. I'm not jumping ship because someone else might do it 10% better.
But if I'm a dentist with HIPPA compliance issues (good example), I don't care about underlying technology. I just want the closest solution with someone who's been there before.
Trying to sell an already-technical user on $20/month hosting is a bit of a joke when there's DigitalOcean or a dozen others after a quarter of the cost... Or less.
Web hosting isn't really even "SAAS" anymore. It's a commodity service.
This is certainly true. Content management systems are a dime a dozen. Locomotive is nice, but others have more developers, features, mindshare, exposure etc. Hard to compete with that.
Still, I believe Locomotive already serves a niche: It is one of the few available ruby on rails cm systems. And it it possible to integrate Locomotive with an existing rails app. That is why I guess their main audience is rails developers who need some content management functionality in their apps. And those do not need hosting.
This is consistent with what they describe in the post: Many people using the open source software, many consulting gigs with developers but only a few hosting customers.
I wonder if a better business model in this case would be some kind of productized service. If access to Didier is a scarce but sought after resource, they might want to try selling support contracts that guarantee a certain amount of Didier's time.
I suppose the good thing is that they will grow as Rails grows, unless someone bigger and badder comes out of nowhere.
But you have to wonder, how do you monetize a community of coders who are already very competent (compared to the PHP ecosphere)?
I think an "App store" of sorts could be the way to go. Just take % cuts off of other's work, and foster it as it all grows organically. Imagine if WordPress had done that themselves... instead of Envato and the like killin it in what could rightfully have been WP's own backyard.
> That is why I guess their main audience is rails developers who need some content management functionality in their apps. And those do not need hosting.
That's a great point, and another illustration that a business model that works for one product might not work for another, even if they appear similar on the surface.
That is correct, a vast majority of our users are Rails developers and we don't have a paid product for them right now. So we'll have to reach larger audiences for the hosting and find a good product for our early adopters. It's not so easy to combine both and that makes our website copy not as clear as it should be.
We're trying to talk to Rails developers because they are the most likely to see the technical possibilities of the product and to other developers because they are more likely to use our hosting solution.
And we also insist on the free and open source side of the business while trying to monetize the project.
I'm just getting through Zero To One, that Peter Thiel book that came out and this is a perfect example of why you should seek new ground and avoid competition. For some reason, every developer thinks every CMS system out there doesn't meet their needs. I don't know if it's because they aren't well-documented or well-architected enough but every dev or company eventually gets to the point there they want a customized CMS for themselves because they think they have a value-add.
I think if they had a very unique value proposition in order to avoid competition, they'd be in good shape. Maybe a CMS just for a specific industry.
I read this with interest as I'm a founder of another CMS - http://grabaperch.com - that I guess is a competitor (although we're PHP & MySQL).
We launched in 2009, and have always been licensed on a commercial basis. This means that we've been able to bundle top notch support in with license fees, and continue to develop the product based on user feedback. I really love the idea of things being open source and there are definite benefits of being so, but in reality it is very hard to make that model pay.
Instead we've gone for the paid license route, meaning that we could - when we were also doing client work - ensure that Perch was a "first class citizen" and not abandoned for stretches while we chased client projects. As the customer base grew, we could dedicate more time to it.
It's still a tough business to be in, but we've carved out a bit of a niche in it. We aim squarely at small design agencies and freelancers who are rapidly building smallish sites for clients. They buy multiple licenses per month and know that we're around to support them and also that we listen and consider features that they need.
Thanks Rachel, I really appreciate your comment. When we introduced our very first paid services, we were very afraid to scare our open source community away and consequently, we were way too shy in our marketing efforts.
But that was a mistake and this led to the situation we are in right now.
And of course, we can only offer limited support to our free users because it would just kill our business otherwise. We'll work on improving our onboarding process and be more agressive in terms of marketing to generate more revenues that every one will benefit from in the end.
At Perch our biggest cost is support in terms of our time and the requirement for more people to scale it, it's why we don't offer any kind of free version.
We actually only hear from about 25% of our customers and only 10% raise more than one query, but if you take a look at our forum you'll see a lot of the support we get isn't even anything to do with our product. We're now experts in the horror that is shared PHP webhosting, we end up helping people with their CSS.
So we have a license fee that covers support. People can come into our forum and we'll help them out. As a business focused product that is massively important. If a designer has used Perch to create a site for their client and they have trouble adding the free blog add-on for example, they need to know they can come and ask us about it. That's the biggest difference between us and a "free" product, you get help when you need it.
"Our only monetization strategy so far has been LocomotiveHosting. We had big hopes for it, but it has gained little traction and too little interest from our users."
Estelle from LocomotiveCMS here. Thanks everyone for the comments! We're in full agreement agreement that we need to improve our marketing, many thanks for the suggestions.
You'll see huge changes on our sites very soon.
We actually paused all our marketing efforts for a while to focus on development but it seems that it has to be our priority #1 right now.
I am the founder of another open source project (https://erpnext.com) and we monetize from the end-user (non-developer community). This is the community which values hosting services else they would need a third party to host your product. If you identify that group, they are more likely to trust your service rather than go with someone else.
If you have a product that is targeted squarely on the developer community, it is hard to monetize unless you are a platform (i.e. GitHub). On similar lines, Wordpress makes money from bloggers, not web designers, hence the "hosting" service is value for money.
Do you target end customers for LocomotiveCMS? Look at your hosting customers and see why they signed up for your hosting. Identify a niche and focus on marketing to that niche.
Blog posts like this will definitely help. Wish you all the best!
No, we don't target the end customers. Though V3 and it's new user interface is definitely aimed as making content editing way more fun for them.
You know, at first if felt really good talking to developers and trying to solve their problems rather than having to provide support to non technical people.
But we are indeed considering serving a niche we think is underserved and that would actually need only a fraction of the features we've developed.
That would be a more manageable project though I hate the idea of letting down our early adopters and all the people who believe in Locomotive.
If there's truly a need and the product is a 10x improvement on the competition (even for a small niche), you shouldn't need to pay people to work on an open source project like this. There are plenty of niches, and the main one I can think of is focusing on a super lightweight drop in CMS for existing Rails apps. Perhaps it generates static files into the `public` directory.
One of the biggest flaws of the CMS space is assuming or requiring that they are completely in control of the application. When in reality, all I need is a CMS for is a subset of pages. At most it can be in control of a subset of domains -- but never all of them.
For example, a common requirement is a faq-like page, a blog section and easily being able to edit other public pages (about, team, contact, index, etc.). Then the real bread and butter of the application is behind some sort of login wall or is all internal and requires custom code and logic. I shouldn't have to stand up two applications to achieve this (increasing application maintenance by an order of magnitude in the process), fight the cms, or roll my own every time.
Ideally I should be able to tell a CMS a single page it can control (or subset of domains), and it takes the existing content and allows editing and saving of it.
Start with that idea, then add premium features like easy a/b testing.
edit... Also, in my experience CMS is a race to the bottom when it comes to client quality. You end up making very little money per project as the person looking for a wordpress/cms solution is either pinching pennies or just plain cheap. The real money clients come from those looking for real solutions (which are almost always custom solutions) to enhance their business' bottom line, not give it a crappy web presence that wont change for the next 10 years.
> For example, a common requirement is a faq-like page, a blog section and easily being able to edit other public pages (about, team, contact, index, etc.). Then the real bread and butter of the application is behind some sort of login wall or is all internal and requires custom code and logic. I shouldn't have to stand up two applications to achieve this (increasing application maintenance by an order of magnitude in the process), fight the cms, or roll my own every time.
I think your approach is good, but LocomotiveCMS takes a different (I think also very valid) approach. A single LocomotiveCMS instance is designed to serve the static pages for dozens or even hundreds of sites. You keep the meat of your application in the platform that fits the project (rails, node, clojure, whatever) and let LocomotiveCMS handle the plain content pages for all of your sites. You can get the content into your app using JSON APIs or you can proxy pass to the pages themselves.
So it's true that you have to spin up two apps the first time, but after that, you can keep using the same instance to add pages for as many sites as you want. You provide the app, LocomotiveCMS provides tools for your clients to edit and create the static pages.
Here's a marketing tip, your comparison page only compares to WordPress. "Better WordPress" doesn't impress me. Try comparing yourself to a better product. One that people are currently paying money for.
Millions of people pay money to wordpress developers, wordpress hosting companies, wordpress themers, wordpress plugin makers, etc. Wordpress runs half the web. I'd say building a better wordpress is a worthy goal.
A majority of those customers won't consider a "better wordpress", either because choosing wordpress is the safe option, or they are invested in the Wordpress ecosystem.
The customer looking at the LocamotiveCMS webpage has probably already decided they want a better Wordpress, and they are trying to compare between the other options available.
I'm not saying they shouldn't compare against Wordpress, but it wouldn't hurt to include a few more comparisons.
I don't think it's debatable that there are people out there familiar with WordPress who don't like it much and are looking for something else.
Whether this is 90%, 50%, or 1% of WordPress developers doesn't matter much. Even in the worst-case scenario it's still going to be a big enough niche if you're able to reach them.
Also, it seems a lot of the comparisons to WordPress are hardly accurate. Most notably is the 'Security' area where it asserts that
> There are a million plugins available that extend your site’s functionality, but each plugin increases your security risk and your maintenance overhead.
but with LocomotiveCMS
> Since LocomotiveCMS is built on Ruby on Rails, you get tons of power without having to rely on a bunch of plugins that can compromise the security of your site.
So, what, is that saying that LocomotiveCMS doesn't have a plugin architecture for porting in additional functionality? Or is it just hubris to the point of saying all extensions are naturally more secure? Or that users would never need to install plugins, because LocoCMS has lots of features already? 'cuz, y'know, WordPress has lots of features too.
Plus:
> [In WordPress, to] make many site changes, you have to download a copy of the database and the entire content folder back to your local installation.
Nope. That's just factually wrong.
> [In WordPress] some assets are stored in a database, and others are in templates or additional places.
... no? Content and configuration is stored in the database, templates and assets are in files. Really wondering wtf they're talking about here.
> And forget about trying to make those custom types relate to each other without significant code slinging.
> While WordPress has multi-site capability, you often run into compatibility issues that can hamstring the production of your sites.
Really? Like ... what? The only things I've ever seen break in multisite was when the developer was doing things incorrectly, trying to hack one thing into another without understanding the system they were working in.
> If you've worked with WordPress, you already know what we're talking about.
I've worked with WordPress for six plus years now, and have no idea what you're talking about.
I've worked with Wordpress for the last 7 years myself, and some of these points aren't too far off the mark. I'm of the belief that I shouldn't have to install a million plugins for stuff that should be built in, and I'm sick of the global loop. On the other hand the module system and Laravel integration I've built at work makes Wordpress rather nice to use for heavy development; clients can build new pages from scratch with all the structure content they want, and have the design never break and always match the rest of the page. I love ACF ;)
But who gets to decide what "should be" built in? Chrome (the browser) for example came out with pretty much nothing but browsing at first, while its competitors - Firefox and Opera, notably - were only adding features (iirc Opera had things like email, bittorrent and IRC clients built in at the time). This left the choice of what a user would like in his browser to that user himself.
I'm sure that most Wordpress installations have no extra plugins at all - and are none the worse off for it.
But out of curiosity - what plugins do you believe should be part of the default WP package?
Opera has always been a little different (I personally like it), but Firefox was not getting tons of extra features when Chrome launched (why would Mozilla do that when they had such a healthy plugin market).
As far as I see it, Chrome got the bulk of its market share through speed and advertising/bundling (advertised on Google, bundled with Flash, etc...).
Considering why this happens, perhaps the issue is... paid support on a small personal project feels like cheating, even if it saves you tons of time and reduces headaches. I guess people take pride in knowing their software stack from top to bottom. For larger projects egos are put aside because the more important factor is reliability.
I don't have any answers of how to change things for your project, but hopefully this comment can be of some use.
In the Joomla world, at least, there are a lot of companies who seem to be making money off of open source plugins. One common model is to allow downloads only after you've subscribed. (Yes, the plugins are typically GPL.)
These usually come with automatic updates for a year for subscribers.
Sometimes this can be bundled with "priority support" for 3x the price.
And, of course, there's always the classic "upgrade to the pro version" pitch
I have worked for a company that did / does a lot of money by providing a closed-source CMS for mainly Rails apps to its clients.
I must say that getting paying customers for any CMS is a lot of work.
If you are going for larger companies, you need to have an entire sales department that is going to try selling your product together with customized solution.
Actually, what worked best for that company was selling a licensed CMS + consulting and building really customized solutions.
Maybe your business could work out this way too, but with an open-source model at the core. You could extend the open source version with some enterprisy features, charge for it and offer support and consultancy in order to build truly customized solutions.
Still, the really tricky part, is selling the product in a market that is pretty crowded by now.
It seems like we're heading in that direction. One thing that LocomotiveCMS did bring us is clients who need a custom CMS. In most cases, they'll start from some of Locomotive features and we build whatever they need from there. These are usually high quality clients though it means that we have way less time to devote to the open source version.
If I were a Ruby guy, I might have contributed code by now. I frequently look at popular PHP frameworks on Github to see if I can improve them. Sorry to hear nobody's volunteering any contributions to your Ruby project.
One recommendation for you: I wanted to try out this CMS after reading the blog post, so I click on the "Get Started" link on your website... it requires me to subscribe to an email list?! Huge stumbling block there. There are SO many CMS's out there, and if I can't get a feel for it within a few minutes I'm going to just move on to the next one.
As a developer, I'm looking for easy-to-find docs. Having it in a downloadable PDF is already not so great... having to register for it is terrible.
I understand your concern. To be honest, until a year ago, we didn't have a CTA on our homepage. We opted for that solution that was meant to be temporary and that should have been replaced by a demo website. And this is one of the many projects that was postponed because we needed to speed up product development.
But once more, this proves that we should pause product development for a while (the only thing that Didier really likes to do) and focus on onboarding, good marketing and a good demo of the product.
I guess the grass is always greener on the other side. My start-up (also roughly a CMS) is considering going open source to increase awareness and the size of our target market. We were also considering continuing to make money via a hosted solution, although their revenue numbers don't get me too excited about the prospect.
Don't think "code & features", think "product". We developers often miss the product side of what we do, yet it's often the gut feeling that makes people follow certain trends while ignoring others. Any solid logic can be defeated by instincts (yes, we too can behave like our girlfriends). A more compelling product is better at sales that a more clever one. Yes, it's more often irrational than not.
From the presentation standpoint, your website likes identity. It's bland and super easy to forget. It just doesn't grab me. Product needs to imprint itself at the unconscious level, it gotta be likable. Use your creative vision or ask for help.
While unrelated to the content, I find it it really hard to read when so much text is in bold. It's hard to focus on the sentence I am reading at the moment as my eyes are unconsciously jumping to the emphasised bits. I guess it shows how powerful bold font might be, and at the same time how negative it can be when abused. I think bold text is great in short paragraphs (e.g. on landing pages) but probably not on a text as long as this.
Yes, it has helped us acquire high quality consulting clients. But we're at a stage where we no longer wish that revenues from consulting fund the project because time spent on consulting is time we can't spend on product development.
Update: Ah, apologies for assuming it's "his" post. The author is clearly a woman and I'm a moron. Sorry.
Original:
I think it's a pretty reasonable assumption that someone who's trying to run a web services company/consultancy would know when his post is on the HN frontpage. If he isn't, that probably says more about the business than anything in the post.
We're in Europe. We made it to the HN frontpage during the night and I have better things to do during the night than anxiously monitoring what progress the post is making.
I wonder what would happen if a) you focused v3 on having features that specifically made it awesome for dentists with HIPPA compliance issues. Or cross-eyed investment bankers. Or someone with deep pockets and an unusual, unmet need and b) shifted the value of open-source from shared development costs to risk-avoidance. Namely: customers have an escape hatch if you cease development because they can update the source, export data into novel data formats, etc.