The difficulties we face to monetize our open source project
locomotivecms.com
locomotivecms.com
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.
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.
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.
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'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.
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 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.
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.
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.
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.
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.
Go for low-hanging fruit. This may stimulate office discussion
http://www.labnol.org/internet/blogging/how-wordpress-makes-...
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!
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.
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.
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.
> 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.
Nope. Easy plugin. No code slinging required. https://wordpress.org/plugins/posts-to-posts/
> 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'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?
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...).
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.
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.
LC;DR - Low contrast, didn't read.
I don't have any answers of how to change things for your project, but hopefully this comment can be of some use.
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 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.
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.
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.
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.
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.