Please don't take this as criticism, because I don't mean it that way. I just want to point out the possibility that the situation you find yourself in is based on your choices, not necessarily on an inability to create a free software business model. I have not looked at GitLab specifically, if the following does not apply to how you do business, then I apologize. But for interest sake, consider the following.
Most software companies work on a "push" based model. They have BAs/PGMs who decide what work needs to be done, make plans and get development in motion. The developers implement the features and after a certain period of time, the features are finished. The business then sells licenses to the software based on the features that exist in the product.
In this kind of business model, you have many problems. First, you have a fairly large up front investment which you need to recover. The initial software development is paid for by the company and you need to find someone who is willing to reimburse those costs. Selling support is untenable because if the product requires a lot of support (meaning that the cost of the support contract is worth it), nobody will use the product. So instead the company must restrict the use of the product to paying customers. In this system, the no-cost, open source version is a loss leader that brings new customers. Such a system may actually be antithetical to free software developers because there is a huge incentive for the company to introduce vendor lock-in so as to push people to the paying version.
However, "push" models are not the only model you could use for development. While they are comparatively rare, "pull" models also exist. In a "pull" model, you avoid doing work unless someone pays you to do it. While it might be bug fixes, it is more likely features. Organizations are willing to pay for specific features because they get a defined benefit for an single up front cost. As long as there are several customers who are willing to pay for development, the cost is shared across those customers.
In such a system, it is the company's actions rather than their IP which is valuable. In fact it would be detrimental to restrict people from getting access to all the features because you lose potential customers. Also in such an environment, it is very important that nobody makes a proprietary version of the software to unfairly compete with you, so licenses like the GPL are incredibly useful.
As I said, examples of this type of model are few and far between. It is unfortunate because I think there is a lot of potential. If you got this far and are interested in one example of a successful "pull" model business, I highly recommend reading: http://www.oreilly.com/openbook/opensources/book/tiemans.htm...
Cygnus was eventually acquired by Red Hat for about $700 million in Red Hat stock. I can't find numbers to back this up, but from memory I believe they had sales of over $100 million per quarter at the time (the best place to look for how Cygnus impacted Red Had after the acquisition is to look at the quarterly reports from the year 2000 on).
I hope that proves interesting. Whether or not GitLab could transition to such a business model is obviously a different question. It is a completely different way of doing business and I don't think you could just tell people to change overnight. However, if you are really serious about exploring options for moving to a more free software oriented approach, I hope the above offers some clues for how to start.
Thanks for the advise, it was interesting reading about Cygnus, I was not aware of their story. At GitLab we already use both the pull and the push model. Since we started there have been people contributing to GitLab (more than 700!) and we encourage more contributions: http://feedback.gitlab.com/forums/176466-general/status/7964...
We also do sponsored development were organizations pay for adding new features.
People and organizations love contributing and sponsoring new user facing features. But other work is not contributed. Release management, dependency updates, security investigations and design updates don't receive much love. Few people want to do the work and few organizations want to sponsor it.
I don't say pull driven software can't be secure (FreeBSD) or that it can't be well designed. But with GitLab we were not happy with the rate of progress on these fronts. So we adopted an open core model to pay people to help with this. This meant our free software (that has the same design and security as the proprietary one) advanced at a much more rapid pace.
We're sure that staying 100% pull driven would not have created such as quality product as GitLab is today. We respect other organizations working with other models (Linux, Rails, etc.) but we're very happy with the choice we made for GitLab.
Most software companies work on a "push" based model. They have BAs/PGMs who decide what work needs to be done, make plans and get development in motion. The developers implement the features and after a certain period of time, the features are finished. The business then sells licenses to the software based on the features that exist in the product.
In this kind of business model, you have many problems. First, you have a fairly large up front investment which you need to recover. The initial software development is paid for by the company and you need to find someone who is willing to reimburse those costs. Selling support is untenable because if the product requires a lot of support (meaning that the cost of the support contract is worth it), nobody will use the product. So instead the company must restrict the use of the product to paying customers. In this system, the no-cost, open source version is a loss leader that brings new customers. Such a system may actually be antithetical to free software developers because there is a huge incentive for the company to introduce vendor lock-in so as to push people to the paying version.
However, "push" models are not the only model you could use for development. While they are comparatively rare, "pull" models also exist. In a "pull" model, you avoid doing work unless someone pays you to do it. While it might be bug fixes, it is more likely features. Organizations are willing to pay for specific features because they get a defined benefit for an single up front cost. As long as there are several customers who are willing to pay for development, the cost is shared across those customers.
In such a system, it is the company's actions rather than their IP which is valuable. In fact it would be detrimental to restrict people from getting access to all the features because you lose potential customers. Also in such an environment, it is very important that nobody makes a proprietary version of the software to unfairly compete with you, so licenses like the GPL are incredibly useful.
As I said, examples of this type of model are few and far between. It is unfortunate because I think there is a lot of potential. If you got this far and are interested in one example of a successful "pull" model business, I highly recommend reading: http://www.oreilly.com/openbook/opensources/book/tiemans.htm...
Cygnus was eventually acquired by Red Hat for about $700 million in Red Hat stock. I can't find numbers to back this up, but from memory I believe they had sales of over $100 million per quarter at the time (the best place to look for how Cygnus impacted Red Had after the acquisition is to look at the quarterly reports from the year 2000 on).
I hope that proves interesting. Whether or not GitLab could transition to such a business model is obviously a different question. It is a completely different way of doing business and I don't think you could just tell people to change overnight. However, if you are really serious about exploring options for moving to a more free software oriented approach, I hope the above offers some clues for how to start.