Ask HN: When does it make sense to develop your product as open source?
5 comments
Tom Preston, the co-founder of Github had some interesting things to say about the benefits of open sourcing almost everything that the company creates. http://tom.preston-werner.com/2011/11/22/open-source-everyth...
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.
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.
If it is released as open source, how do you identify potential clients for your services? And under a professional services model, they are clients, not 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.
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.
> If it is released as open source, how do you identify potential clients for your services?
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.
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.
"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."
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?
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?
> 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.
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.
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.
1. My understanding is that Red Hat started out selling Red Hat Linux on disks - the internet in 1994 was not much of a distribution channel for large pieces of software. I would add that the attractiveness of a free OS can justify a larger expenditure on support than most tools - i.e. Red Hat solved a big problem for a lot of IT organizations with deep pockets.
see: http://fedoraproject.org/wiki/History_of_Red_Hat_Linux
see: http://fedoraproject.org/wiki/History_of_Red_Hat_Linux
When the market is commoditized and ready for standardization.
Standardization that understands the practical difficulties of current development model would be a huge advantage. In your case, standardization of data access (RDBMS/NoSQL), multitenancy & stateless/stateful scaling.
Standardization pushed for the sake of it will end up like SOAP (vs REST) or Entity beans (vs Hibernate).
You mention developing a PaaS product, then you go on to describe a business model based around professional services (PS). By definition, they contradict each other. Also, a product-based business and PS are very different businesses and has different ways of scaling revenue and marketing.
Decide which is it first.
Decide which is it first.
Right, so in the case of releasing the product as open source, the product is not the business, it's something to base a PS business around. I see this as something similar to, say, 10gen with MongoDB.
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.
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.
I don't seem to be able to edit my post, so I'll add this clarification: it's a PaaS-like product that you'd host both internally and in the cloud to provide a homogenous platform for your developers across the entire runway.
The model we're leaning towards currently is to release the software as open source, to encourage a more rapid adoption, while the company sells ongoing support contracts, custom integration, training and consultancy. Because of the nature of the project, it doesn't make sense for it to be offered as a hosted service.
When does it make sense to do this, and when is it more likely to cause failure? Is it something that would immediately put investors off, or would they still see value in it? Is it a model suitable only for bootstrapped companies?