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.
The difficulties we face to monetize our open source project
21–30 of 51 posts
Re: The difficulties we face to monetize our open source project
#22Here'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…
Re: The difficulties we face to monetize our open source project
#23We 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
#24LC;DR - Low contrast, didn't read.
Re: The difficulties we face to monetize our open source project
#25From 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
#26Earlier 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.
Re: The difficulties we face to monetize our open source project
#27If 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…
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"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
Re: The difficulties we face to monetize our open source project
#29I'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…
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.