Live data from Hacker News

The difficulties we face to monetize our open source project

locomotivecms.com

21–30 of 51 posts

Re: The difficulties we face to monetize our open source project

#21

Earlier quoted context omitted.

I like how people just assume that HN is where the writers of any random blog post will go to respond to questions.

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.

[deleted]

Re: The difficulties we face to monetize our open source project

#22
post #3

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.

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 pl…

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 ;)

Re: The difficulties we face to monetize our open source project

#23
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.

Re: The difficulties we face to monetize our open source project

#25
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.

Re: The difficulties we face to monetize our open source project

#26

Earlier quoted context omitted.

I like how people just assume that HN is where the writers of any random blog post will go to respond to questions.

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.

Re: The difficulties we face to monetize our open source project

#27

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.

Exactly this. 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, i…

> 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.

Re: The difficulties we face to monetize our open source project

#28
post #16

"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." http://suckysales.locomotivehosting.com

So true, overall #2. There is room of improving the conversion rate. Also what's a 'non white label' hosting but with a custom domain?

Re: The difficulties we face to monetize our open source project

#29

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 h…

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.

Re: The difficulties we face to monetize our open source project

#30
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.
Post reply on HN