I've got one data point for you, though I don't think you can guesstimate income based merely on one factor, especially not github stars (we only have 295).
My company is based on Open Source software (Webmin, Virtualmin, Cloudmin, and Usermin), and it sounds sort of similar to your situation. When we started the company based on this stuff we had several major companies in our target market (and we chose our target market, and chose to focus on Virtualmin rather than other features of Webmin, because that market already knew us and used our software in visible ways) using at least one of our projects, almost a million downloads a year, and my co-founder and I had both been making a decent living doing contract work based on it and writing about it.
Today, Webmin has about 1 million installations worldwide (and has grown to ~3.5 million downloads per year). We make enough money from our small proprietary extensions to Virtualmin and Cloudmin to support three modest salaries. It is not $100k/year for any of the three people working on it, though it's not an outrageous dream to think we could get there..we've had much better years than we're having this year or last year, however, so revenue is not necessarily growing like gangbusters, despite our userbase roughly tripling in the time the company has existed and still growing at a comfortable clip annually. Ours is sort of an open core model, though the core is very large (~500kloc) and the proprietary bits are very small (~20kloc), which may be part of our revenue problem.
I think there are some things you're probably underestimating (not to say it should discourage you, I'm just trying to open your eyes to some challenges you will face that you might not expect):
When you sell Open Source software, support is your biggest value add, even if you don't want to be a support company. Support costs a lot of time and money to do well. Time and money has to be balanced between making things better and supporting existing users on the current version (true of proprietary as well, but proprietary vendors don't have a million people using the free version and expecting help). Growing the free user base (which can be a side effect of having people working full-time on it) can paradoxically lead to less time and money for making the software better. We fight this battle all the time. To make our current customers and OSS users exceedingly happy with our level of support is to severely limit our ability to deliver next generation solutions. We run on such a shoe-string, and compete with such huge players, that it's always a struggle to deliver both (and we fail plenty).
So, plan to hire someone to help you support the software, eventually. If we were comfortable leaving our forums to "the community" and not bothering to have an official company voice present every day helping answer the hard questions, we could increase our own salaries by a lot (we pay our support guy more than we pay ourselves), but I don't know that we'd continue to see the growth we've seen in our user base, which we also value. We make things because we want them to be used, not just because we want to make money.
Get used to having demands thrown at you every day. The level of documentation and completeness and rapidity of development expected of a product is vastly different than that of an Open Source project, or at least the way you have to respond to it is different...even for users of the Open Source versions. We have over 1,000 printed pages worth of documentation, plus a couple hundred pages of online help, and still get complaints about our documentation regularly. And, we have more "features" than any other product in our space, including the two big proprietary competitors, and yet still get feature requests all the time (and it's harder to say no than to just implement it, which can hurt usability). A million users generates a lot of feedback. It's a very high volume of demands to answer to. Ignoring them pisses people off, saying no pisses people off, and saying yes often risks making the product worse or more complex for the average user, hurting long-term growth. Even saying, "Not right now" pisses people off. You're going to piss a lot of people off, even if you're just trying to make the best software you can and make a decent living.
I think what I'm trying to say is, think about it for a while before committing to your plans. If you currently have steady income, hang on to it while you sort out a few details.
Try to firm up what your users would pay for your value add. Try to figure out how many of your users would pay for your value add. The only sure way to do this is to actually have users pay you something for your value add.
Try to figure out how you will automate support (hint: You can't, because automated support almost always sucks; even Google has awful automated support, and they're good at almost everything.) At least figure out how you will streamline it and offload it; have an active forum already? If not, get one. Have a community of people talking about your software already? Get one. If Open Source based business were a Pokemon, community would be its special ability. So, you should start cultivating that now, even before money is coming in.
Interesting to hear from someone both brave enough to bet on webmin, and lived to tell the tale! :-) I'm afraid I don't have the best impression from webmin etc - but then again I'm not the target customer.
Having had a look at your product page it strikes me that you seem to be under pricing though? $99 seems way cheap if you add any value at all. I suppose it's a though market, but $500 or even $1000 sounds more reasonable. Loose half customers, make more money, have fewer to support?
I'm guessing you've gone back and forth on this a lot; just hoping a completely outside perspective might help - even if you end up going with your current pricing model.
We're experimenting with lower pricing, at the request (demands) of a handful of loud users. It has, so far, been a mistake. Revenue is down despite increased sales...sales didn't increase enough to make up for the lower prices.
Our previous pricing was $139 up to $499 for the first year of Virtualmin Professional, depending on number of domains hosted, and renewals costing about 1/3 that. Current prices are $99 to $249, I think. So, it is significantly discounted.
This is also a bit of a stop gap while we rewrite our store and license manager to accommodate monthly subscriptions and to better handle reseller accounts (users who are hosting providers that buy many licenses and expect steep discounts because our competitors provide steep discounts to hosting providers). This all coincides with a migration from Drupal 6 to Drupal 7, which has been a nightmare and has taken longer than every previous website migration we've done, including two migrations from completely unrelated content management systems and shopping carts.
Anyway, you're probably right about pricing. We'll decide after we launch the new site and have ways to provide more flexibility in purchasing to our various types of customer.
I'd like to hear about your poor impression of Webmin. What, specifically, makes Webmin not something you would consider for your servers? I know about some of the persistent myths that follow Webmin around: Insecure, breaks things, incompatible with my favorite distro, ugly code (this is kinda true). But, many of those come from grumpy hard-line command line administrators that think no one should be allowed to be a system administrator if they can't do it all in a shell...we'll never win those folks over. But, I still like to know what negative things people think of Webmin and why they think it. I've pretty much devoted my entire professional career to Webmin and things related to it (my previous company also was based heavily on Webmin, and I wrote a book about it). It matters a lot to me that it always gets better; and, it matters to me that people are judging it on its actual merits (and flaws) rather than inaccurate beliefs.
> This all coincides with a migration from Drupal 6 to Drupal 7, which has been a nightmare and has taken longer than every previous website migration we've done, including two migrations from completely unrelated content management systems and shopping carts.
Aww, I'm so glad I'm not on your team for that ;-) Even without following Drupal closely I can imagine your pain: new programming/design patterns, new php language features, major refactoring and a change to more modern rendering pipeline, templates and perhaps a new caching layer on top of perhaps a restructured data-layout? Am I close?
> I'd like to hear about your poor impression of Webmin. What, specifically, makes Webmin not something you would consider for your servers? I know about some of the persistent myths that follow Webmin around: Insecure, breaks things, incompatible with my favorite distro, ugly code (this is kinda true).
Mainly bad code and insecure (way back). But:
> But, many of those come from grumpy hard-line command line administrators that think no one should be allowed to be a system administrator if they can't do it all in a shell...we'll never win those folks over.
That's me ;-) As I said, not your target customer. Mainly I don't really want the level of access webmin needs to be effective, exposed as a web service. While that might be mostly religion at this point; I also realize that it mostly makes sense if no other core data is exposed as a web service. This is obviously the case for many people and businesses. [ed: just not for me as I prefer ssh/the command-line]
Would two-factor authentication and certificate-based authentication help alleviate some of those security concerns? Because Webmin has both of those.
We actually take security seriously, as any software that provides root-level access to a million servers must, though I don't pretend we will ever be bug-free or that we can ever guarantee security (even SSH has had major security bugs). We're considering setting up some sort of bug bounty to help sniff out security bugs, but haven't figured out how best to implement that.
I actually thought a bit about that after posting. I would be more inclined to use a web based admin interface today, than just a few years ago; the TLS stack is not as bad as it was; we've come further wrt ciphers - and the web servers themselves have seen (more) hardening.
The thing is; I already use ssh. Adding another network service doubles the attack surface.
Then there's the ux problem for browsers and certs. Using certs with ssh is complicated enough (it's still on my todo-list, I use/require keys - but key management is not trivial for more than a handful of servers).
Ssh also finally have easy/proper 2fa support now: setting up totp+keys is quite trivial. Add password+totp for sudo locally and you have half-decent ux and security.
And while ssh has had some security issues, it's been a while since the last big one. In contrast with all the things that go wrong with web apps (xss, session-hijack etc).
All that aside, certs+2fa (and the ability to disable pw auth) goes a long way.
Btw for any other grumpkins reading; I just discovered scoop and found out powershell seems to finally be usable in windows 8.1 pro even for part-time ms users.
Run>powershell
set-executionpolicy unrestricted -s cu
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
#yeah, I know - no signarure, code from curl...
#but this is windows, beggars can't be choosers
scoop bucket add extras #optional
scoop install ssh
If you want oneget, it's in the extras-bucket iirc:
scoop install oneget
But while scoop could use some love (eg vlc is a point release behind oneget/chocolaty) -- it's much nicer than the FindPackage mess IMNHO.
My company is based on Open Source software (Webmin, Virtualmin, Cloudmin, and Usermin), and it sounds sort of similar to your situation. When we started the company based on this stuff we had several major companies in our target market (and we chose our target market, and chose to focus on Virtualmin rather than other features of Webmin, because that market already knew us and used our software in visible ways) using at least one of our projects, almost a million downloads a year, and my co-founder and I had both been making a decent living doing contract work based on it and writing about it.
Today, Webmin has about 1 million installations worldwide (and has grown to ~3.5 million downloads per year). We make enough money from our small proprietary extensions to Virtualmin and Cloudmin to support three modest salaries. It is not $100k/year for any of the three people working on it, though it's not an outrageous dream to think we could get there..we've had much better years than we're having this year or last year, however, so revenue is not necessarily growing like gangbusters, despite our userbase roughly tripling in the time the company has existed and still growing at a comfortable clip annually. Ours is sort of an open core model, though the core is very large (~500kloc) and the proprietary bits are very small (~20kloc), which may be part of our revenue problem.
I think there are some things you're probably underestimating (not to say it should discourage you, I'm just trying to open your eyes to some challenges you will face that you might not expect):
When you sell Open Source software, support is your biggest value add, even if you don't want to be a support company. Support costs a lot of time and money to do well. Time and money has to be balanced between making things better and supporting existing users on the current version (true of proprietary as well, but proprietary vendors don't have a million people using the free version and expecting help). Growing the free user base (which can be a side effect of having people working full-time on it) can paradoxically lead to less time and money for making the software better. We fight this battle all the time. To make our current customers and OSS users exceedingly happy with our level of support is to severely limit our ability to deliver next generation solutions. We run on such a shoe-string, and compete with such huge players, that it's always a struggle to deliver both (and we fail plenty).
So, plan to hire someone to help you support the software, eventually. If we were comfortable leaving our forums to "the community" and not bothering to have an official company voice present every day helping answer the hard questions, we could increase our own salaries by a lot (we pay our support guy more than we pay ourselves), but I don't know that we'd continue to see the growth we've seen in our user base, which we also value. We make things because we want them to be used, not just because we want to make money.
Get used to having demands thrown at you every day. The level of documentation and completeness and rapidity of development expected of a product is vastly different than that of an Open Source project, or at least the way you have to respond to it is different...even for users of the Open Source versions. We have over 1,000 printed pages worth of documentation, plus a couple hundred pages of online help, and still get complaints about our documentation regularly. And, we have more "features" than any other product in our space, including the two big proprietary competitors, and yet still get feature requests all the time (and it's harder to say no than to just implement it, which can hurt usability). A million users generates a lot of feedback. It's a very high volume of demands to answer to. Ignoring them pisses people off, saying no pisses people off, and saying yes often risks making the product worse or more complex for the average user, hurting long-term growth. Even saying, "Not right now" pisses people off. You're going to piss a lot of people off, even if you're just trying to make the best software you can and make a decent living.
I think what I'm trying to say is, think about it for a while before committing to your plans. If you currently have steady income, hang on to it while you sort out a few details.
Try to firm up what your users would pay for your value add. Try to figure out how many of your users would pay for your value add. The only sure way to do this is to actually have users pay you something for your value add.
Try to figure out how you will automate support (hint: You can't, because automated support almost always sucks; even Google has awful automated support, and they're good at almost everything.) At least figure out how you will streamline it and offload it; have an active forum already? If not, get one. Have a community of people talking about your software already? Get one. If Open Source based business were a Pokemon, community would be its special ability. So, you should start cultivating that now, even before money is coming in.