Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Open sourcing our product?
29 points by robot on Mar 23, 2011 | hide | past | web | favorite | 11 comments
Hello, we are a startup developing a mobile hypervisor for ARM processors and Android/Linux. Our IP involves the hypervisor, the ARM-specific layer, and the linux virtualization interface.

Lately we are getting a lot of requests from educational institutions and mailing list subscriptions have reached more than 100 people. The interest is due to the earlier versions being open and the comprehensive documentation. However, the latest version, with business/competition reasons are closed.

How do you think we should proceed? If we allow people to use a smaller version as open, there will be much more people using and learning our solution. On the other hand I would prefer to avoid competition to reach our sources.

This also fits the release-early/release-often approach. By getting feedback from people we get a better direction.

I get the feeling that gaining popularity outweighs the disadvantage of competitors seeing our code. What do you think?

Edit:

* We already had up to v0.3 of the hypervisor released as GPLv3, this excluded the ARM-layer and virtualization interface.

* We intend to license it as a product and we don't plan to build an open source consultancy business. The open intention here is for gaining traction.




If you open-source under the GNU General Public License (GPL) then competitors would be prohibited from re-using your code without applying the same license to their codebase.

Would looking at your code be sufficient to put you at a disadvantage or would preventing competitors from re-using your code be a sufficient defence?

edit: Sorry, it's actually the GNU General Public License (GPL).


Good point. Bear in mind that as long as all contributions come from you, you can both release a GPL branch and have another proprietary branch with custom code you don't want to make public.

This does create a problem though: if you are accepting outside contributions to the GPL version, you can't incorporate these into the proprietary version without having the contributors sign an agreement which allows you to do so.


* One practical question is whether you can do a _useful_ subset of your stuff as open source... if the open source part is worthless without the "proprietary icing" then nobody will care about it, so you get no value from open source.

* A related practical question of course is whether there are customers who will still want to buy the proprietary icing even though there's an open source useful subset.

* How hard is it for competitors to replicate your proprietary icing? Is the community likely to replicate it?

* One of the main competitive advantages of most open source companies is that the key upstream developers behind the project work for the company. Do you have these developers? If so others will be at a disadvantage when it comes to offering support and services.

* Do you want a business that is based on license fees or one based more on support and services?

* Do you have a good way to market the product and get a lot of people interested, other than through an open source project?

* Do you want to spend time on community building and ensuring outside contributors can be productive? Can you put development discussions in the open?


Are your paying clients the same people clamouring for open-source?


The above question is very valid - with open-sourcing your code you will have to get into the 'community management' game, especially if you think you'll be taking contributions in the form of code sometime soon.

If you customers are already asking for it to be open-sourced, or if you have partners in mind who will support this endeavor, this is a good start. If, on the other hand, you open-source without a good PR push to partners/customers/developers it's like a tree falling in the forest; will anyone be around to listen?

We open-sourced from the beginning and then found clients; it was a long haul. We eventually found a toehold in developing countries, and were able to build up client credibility from there. If you already have a plan for using the OSS to sell right away, then maybe this plan is for you.


I think no serious customer for this technology would require open source, they would be happy to have it in commercial terms.

However, non-customers can be a lot of people which would spread the name by word-of-mouth. Also those customers who intend to buy it will get a feeling of what they are getting, instead of you describing a black-box with significant marketing efforts.


Unless your product can really benefit from a strong network effect in the open-source community without compromising your competitive edge, I wouldn't do it.

However, if you feel the potential to gain traction outweighs the threat of losing an edge (or a paying customer, since they can just use your code), open-source the engine, but hold back on the parts that are unique to your offering and/or make your engine easy to work with (like a GUI, simplified wrappers or builds for different platforms), though this depends on the nature of your product.


Hasn't also VMWare announced some kind of Android hypervisor recently? In that case, I feel that a product by a small startup may have trouble getting enough attention if it is also closed-source.

(But beware of taking business advice from me, who am not running a company)


Since GNU and all the other open source licenses won't let you achieve your commerical goals, you have to bank on legal technicalities.

Not entirely sure, but I'd say Magento uses one of the following ways. They claim open-source, but I was never able to figure out how.

Summary

1. Dual license. Add value through closed-source features, services, etc... on the commercial licensed.

2. Have your commercial product piggyback on the open-source creation.

3.Software as a Service.

4.Offer support, consulting, some type of service to assist the (free)open source product.

For a larger introduction go to http://en.wikipedia.org/wiki/Commercial_open_source_applicat...

Does anyone know how mSQL was structured before it got sold?


I think it's worth reminding the story of BricaBox, initially a startup led by Nate Westheimer, and when they closed down, they decided to open source the project : http://code.google.com/p/bricabox/ http://innonate.com/2008/06/19/bricabox-goodbye-world/ Maybe some benchmark to take out of it?


You may want to have a closer look how Xen (acquired by Citrix) handled this, considering the similarities. Their kernel code and the core tools have always been open source (largely GPL, I think), with various closed-source value-add.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: