But a deeper question is what problem are you trying to solve with another PaaS product that is not already served by the likes of Heroku, Dotcloud, Stackato, OpenShift, CloudFoundry, etc?

The last two (OpenShift and CloudFoundry) are already open source PaaS solutions that you can use either on-premise or hosted externally. Read more on my post comparing these four providers. http://appsembler.com/blog/paas-bakeoff-comparing-stackato-o...

I can tell you from experience that building and supporting a PaaS is a lot of work, and I think it will be difficult to make it sustainable unless you are offering it as a hosted service.

The only other provider that I know that is not offering a hosted PaaS is ActiveState's Stackato, and they have 15 years of experience selling to enterprise customers.

How do you ensure that those downloading early versions of the software have a positive enough initial experience to commit to its use, in the absence of support...i.e. how do you get them to put up with perceived bugs, lack of features, cumbersome workflow, etc without some hand holding? It seems to me that a lack of upfront commitment contributes to few open source projects obtaining critical mass.

Products released for free start several disadvantages - the user has low expectations for value, support costs are unfunded, and the loose relationship between the developer and the user makes it difficult to have long insightful discussions about the user's needs.

Ultimately, the value proposition of the project you describe needs to fall within those typical of B2B, not ad supported smartphone apps.

The last question is, are you scratching your own itch as a developer with this project, or is it a startup idea?

Good luck.

I think there's two parts to that. There's more traditional marketing, where you're offering a solution, which just happens to utilise your own open source product, and then there's engagement with existing users who have indicated, through support and discussion channels, that they're interested in the product but need something more.

> Products released for free start several disadvantages - the user has low expectations for value

To an extent, expectations can be managed. In my experience, a professional-looking web site with well-written tutorial and reference material can make a big difference to the initial impression.

> support costs are unfunded, and the loose relationship between the developer and the user makes it difficult to have long insightful discussions about the user's needs.

But is that not mitigated by the offer of paid support? Then support costs are funded, and there is a stricter relationship between vendor and customer. Is that much different to the relationship with a customer you've actually sold the product to?

> The last question is, are you scratching your own itch as a developer with this project, or is it a startup idea?

It started out as an itch while working for a previous employer, but it wasn't scratchable there. So now it's a startup idea.

We know what product we want to build, we're just not sure what kind of company we want to build around it. As it's still in development, we don't have to make the decision yet, but it's something we need to think about along the way.

This heads toward what I was, perhaps inarticulately, getting at.

In order for your product to gain traction, that strategy requires users to suffer up the learning curve without your help, or it requires you to offer free support to non-paying customers.

It's a solid way to avoid getting to "No." I'm not convinced it's a solid conversion strategy and thus an efficient use of runway...at least in the free support scenario. On the other hand, a no-support strategy doesn't really sell what you want to be selling.

To me, as essentially a B2B solution, it's gotta' either worth money out of the gate, or considered a non-starter. If users can muddle along with it for free, then the value proposition of $10,000 a year in services is a tough conversion, particularly if it is targeted at small shops. If it is targeted at large shops, then it needs to be priced at $10,000 a month just to fund the level of support required.

To come back to my final question, are you going to use this PaaS to build the PaaS?

That wasn't how I was looking at it. I was thinking of it more as being a free product for those people who can comfortably use it without support, and essentially a paid product for people who need the support. Isn't that the usual "open source for enterprise" model -- for example, Red Hat?

> To come back to my final question, are you going to use this PaaS to build the PaaS?

I'm not sure how that question makes sense. It's a piece of software, not something we're deploying ourselves. If it was open source, it would probably be hosted (source, downloads, documentation and all) on GitHub. Of course we'll have 'dummy' apps we deploy with it for testing, but that's not the PaaS itself.

see: http://fedoraproject.org/wiki/History_of_Red_Hat_Linux

Decide which is it first.

By 'service' in this case I'm really talking about internal services that an IT department provides to developers, rather than something hosted by a third-party, and I use the term because it's analogous functionality. By having a product that you can run yourself, you can maintain a coherent system that works across the whole development runway, reducing deployment failures that are caused by mis-matched environments. (This is very much came from an itch that needed to be scratched.)

Because it's something for an in-house IT department to provide, just as they would provide code repository hosting and bug tracking, there would likely be a need for training, for consulting, and for integration with existing business systems.