@mherrmann - There are various ways you could monetize Helium and be open source - here are a few ideas. All of them assume that you will be open sourcing your code. The reason for open sourcing this would be to basically achieve wider adoption which will in turn allow you to monetize 5-10% of your audience (Enterprise customer for example).
1. Open Core Licensing - You could create a community edition and an enterprise edition. The community edition would be completely open source and available for free. While you work on the community edition you could identify the 5% of additional features that certain customers (Enterprise for example) would pay for. I think this is a pretty fair way to balance between giving away a free product and creating an enterprise/professional edition where you'd charge a license fee from customers who would have the ability to pay for it. One of the challenges with this model is to make sure you find the right balance between the community and enterprise edition since some people will be upset that certain feature aren't released in the community but make it into the enterprise edition.
2. SaaS - If you open source it and gain widespread adoption - at some point it might makes sense to create a service that allow users to run these tests on the cloud and create a complete suite of features around it. Many developers are happy to pay a service fee for using an hosted version of the open source software that allow them to not deal with hosting, patching and servicing that software. If you do that releasing it under the AGPL will give you a competitive advantage since if someone would like to create a hosted service and improve the open source software, they would have to release all changes to the community (or license a commercial version from you), however if you decide to add some secret sauce in the hosted solution, you ARE NOT required to release it to the community since you could license it under a commercial license to yourself.
3. Offer professional services, support and training - Once developers will start using this in their workflow and start being dependent on that software, they will want the peace of mind of paying for support (or the ability to contact you and ask questions). You could have various SLA of support. For examples: Community edition (FREE) would have access to community forum where users could help each other - at first you'd seed that forum with your own support to kickstart the community. Then you could offer several level of support, from email (9-5 or 24/7) to phone support to various customers. Additionally you could offer up to a certain amount of training or consulting to write custom tests for customers who will need your help integrating this into their workflow. Most often people will opt for paying for a basic license even if the software is free just so they have someone to nag and talk to if things go south.
There are more ways that you could monetize open source - if you found this reply useful and would like to learn more - feel free to reach out to adam (at) binpress (dot) com - I am the co-founder at http://www.binpress.com - the marketplace for commercial open source - we're on a mission to help developers monetize their open source projects.
@adambenayoun Many thanks for all these suggestions.
I see several advantages with open sourcing our product. Most notably, wider adoption and community support available on the net.
Unfortunately, all three options you propose defer the point in time from which we can earn money. For a startup, this is very risky. If we run out of resources before say we have enough users to set up a SaaS service or offer support & training, we will go bust with nothing but wasted money and time on our balance sheets.
I am sorry to be so direct, but I think the three options you propose are not currently viable for us. We might revisit them later though, and I might be in touch via your email! - when we know more about the limitations of our current approach.
Michael
No need to apologize :) As another user in this thread suggested - ultimately this is your company and you'll decide what is the best course of action to turn it into a profitable business. By all means do whatever is possible to make that happen and don't be afraid to experiment.
I suggested a few ideas that could work and would basically allow you to enjoy from both world (both open sourcing your product and monetizing it) however I can understand if you think you don't have the time to get the kind of adoption you'd need to successfully open source it.
Additionally this could be done backward - you could start with your current model and at some point once you are more economically confident switch to another model that is more open source friendly.
It is super-tough to find a balance... take for example the Sencha/ExtJS community where there are problems like a paid support forum that free users can't access even when their own posts are moved there after being reclassified as feature requests / bugs:
There are more examples in that forum demonstrating that while trying to appease those in need of a community edition, it's easy to wind up 'doing it wrong'.
Edit: not focusing on any particular method; just pointing out that any balance between commercial/open source can cause hard feelings and takes extra work to manage
I was actually talking about finding a balance between the community edition and an enterprise edition (see Nginx plus for example).
As far as I would be concerned, Forums should be open to everyone (paid and non-paid) customers and support provided by the community for the community.
Paid support could be additional add-ons in the forms of email and phone support with varying level of responsiveness (a-la-SLA).
FWIW, it's usually pretty easy to find examples of people complaining when companies split up their functionality, especially when they are moving the other way (from open source to commercial):
People will always complain - that doesn't mean the company aren't successful at what they're doing. I've been using nginx for a very long time and started when their docs were in russian and hardly translated into english - I applaud them for doing that step and creating nginx plus - I suspect that in the future I will need/want to pay them a license fee.
If my company is creating lot of value and part of that value is enabled by software I use - I think it's only natural that I pay back some of the proceeds to support the software I use, especially if in the process I'm getting more features and better support.
Different companies do get it right to varying degrees. Can you link to any specific incident where one of these companies resolved an issue with the open source aspect of their product that left a disgruntled user more 'gruntled'?
1. Open Core Licensing - You could create a community edition and an enterprise edition. The community edition would be completely open source and available for free. While you work on the community edition you could identify the 5% of additional features that certain customers (Enterprise for example) would pay for. I think this is a pretty fair way to balance between giving away a free product and creating an enterprise/professional edition where you'd charge a license fee from customers who would have the ability to pay for it. One of the challenges with this model is to make sure you find the right balance between the community and enterprise edition since some people will be upset that certain feature aren't released in the community but make it into the enterprise edition.
2. SaaS - If you open source it and gain widespread adoption - at some point it might makes sense to create a service that allow users to run these tests on the cloud and create a complete suite of features around it. Many developers are happy to pay a service fee for using an hosted version of the open source software that allow them to not deal with hosting, patching and servicing that software. If you do that releasing it under the AGPL will give you a competitive advantage since if someone would like to create a hosted service and improve the open source software, they would have to release all changes to the community (or license a commercial version from you), however if you decide to add some secret sauce in the hosted solution, you ARE NOT required to release it to the community since you could license it under a commercial license to yourself.
3. Offer professional services, support and training - Once developers will start using this in their workflow and start being dependent on that software, they will want the peace of mind of paying for support (or the ability to contact you and ask questions). You could have various SLA of support. For examples: Community edition (FREE) would have access to community forum where users could help each other - at first you'd seed that forum with your own support to kickstart the community. Then you could offer several level of support, from email (9-5 or 24/7) to phone support to various customers. Additionally you could offer up to a certain amount of training or consulting to write custom tests for customers who will need your help integrating this into their workflow. Most often people will opt for paying for a basic license even if the software is free just so they have someone to nag and talk to if things go south.
There are more ways that you could monetize open source - if you found this reply useful and would like to learn more - feel free to reach out to adam (at) binpress (dot) com - I am the co-founder at http://www.binpress.com - the marketplace for commercial open source - we're on a mission to help developers monetize their open source projects.