Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How big does an open-source project need to be for a lifestyle business?
196 points by jnbiche on June 27, 2015 | hide | past | favorite | 111 comments
Specifically, about how many "stars" on Github would such an open source project need to start realistically thinking about turning it into a lifestyle business, since GH stars are probably the most prominent quantitative indicator I know of in this area.

I've got an open source project that has grown fast with relatively little promotion. I know that a good number of companies are using it in production. I also know of a good way to monetize it, while keeping the existing software exactly like it is (not "open core" but somewhat related).

Is this a pipe dream, or do I have a realistic chance into making this a lifestyle business that -- with hard work -- can start providing a reasonable income (say $100,000/yr) within a year or two?




You can turn everything into a business as long as you have a reasonable business plan in place and know that users are willing to pay for some extra features or service.

Story time: 2 years ago I started to learn frontend web development from various online courses. I had zero technical background and no intention to make money. Within few months I learned enough to create my first WordPress theme. It was terrible but it worked . I made few more themes and never did anything with them. I made like 6 themes and just deleted theme few months down the road. Then I decided to submit one theme on WordPress.org just to see if it gets approved. Themes goes through review and someone would evaluate my code and that's what I was after. Long story short my themes now have been downloaded over 1,000,000 times and I have turned it into 6 figure a year business.

While I haven't sold a single theme yet, apparently you can recommend hosting and premium plugins that goes along with your themes and make a decent income.

For those interested you can visit site at: https://colorlib.com/


> I have turned it into 6 figure a year business.

> While I haven't sold a single theme yet

What?


Yes, that's correct :) Most income comes from advertising, paid reviews, sponsorship, affiliate products (hosting, plugins, premium themes from other developers).


As he said, he finances via direct advertisement. Not by selling products, but by recommending additional features.


He has very popular themes that he gives away, and then advertises for paid products on his theme's download pages (presumably).


sponsorships


I still do not understand how 1M free theme downloads translate into 6 figure business.

Does that mean every 10th downloader actually gets you a comission of $1 on some affiliate purchase or does that mean that every 100th downloader buys something generating $10 in affiliate income?


I don't know why but I feel theme is not the most typical open source project.


Mike Perham has done a great job of turning two successful open source projects (Sidekiq and Inspeqtor) into successful businesses.

If you're interested, I recommend listening to his interviews on the ChangeLog Podcast (https://changelog.com/159/, https://changelog.com/130/, https://changelog.com/92/) where he talks about how he monetised those products.

I'm pretty sure that succeeding in this is not going to be a matter of how many "stars" your project has, but rather a function of the dollar value of the problem your software solves and how well you market the paid product. You should start that marketing now by providing a link to your project :).


Thanks for mentioning me. I'm happy to answer questions.

You're absolutely right though: your project is only as valuable as the problem you are solving. When someone told me early on that switching from Resque to Sidekiq was saving them $3000/month, I knew that there was a business here.


Thanks for the excellent resources, I'll look that up.

> You should start that marketing now by providing a link to your project :).

Well, I haven't even created the paid product at this point, it's still early in the game. Just trying to get a feel for the potentials.


> Thanks for the excellent resources, I'll look that up.

You're welcome!

> Well, I haven't even created the paid product at this point, it's still early in the game. Just trying to get a feel for the potentials.

Sure, but you're at the top of Hacker News right now and there's zero downside (and lots of upside) in getting your project in front of a bunch of developers. Even if they don't start using it right away, maybe it will stick in their minds and then six months down the track (when you do have a paid version) they'll Google it.


Thanks, didn't even know about Inspeqtor.


I created Open Exchange Rates[0] as an open source project four years ago, publishing free currency data into a GitHub repository.

It was launched alongside money.js[1] (a minimal JavaScript currency conversion library), designed to work seamlessly together and both found a brilliant response and grew an organic community.

Hundreds of tutorials and thousands of posts and mentions later, GitHub eventually contacted me and politely asked me to take down the exchange rates repository, because they were being hammered by people requesting the data - only at this point did it occur to me that I'd created something of genuine value, and (6 months of fretting and tail-chasing later) I opened up a paid option.

For me the key thing was: I never intended to create a business. It was (and is) a labour of love. We've since grown to be the industry-leader for our area - "good enough data" for the startup and SME market - and count Etsy, KickStarter, WordPress and Lonely Planet among our clients.

Although it's no longer truly open source, 98% of our users are still on the Free plan, which will very soon be expanding to include all features (so, no more limiting by price tiers) - this is how I still feel so passionate about it.

I can't wait to publish the next steps in our journey - where we're opening everything up to the community and marketplace. I don't like where the industry is heading (competitive, closed, secretive) and we've chosen to move towards transparency and sharing.

I like businesses built on a core of open source community, because they're in service to the people who are actually building the products, rather than those in the traditional 'upper levels'. This means there's really no "sales process" (which I'm massively allergic to) - apart from the occasional grilling from the accounting department, who may find it hard to trust a business based on open source principles.

Good luck!

[0] https://openexchangerates.org

[1] https://github.com/openexchangerates/money.js


Really interested by the pricing on your signup page (https://openexchangerates.org/signup), where you have the prices from most expensive on the left to cheapest on the right. I have mostly seen (and always built) these the opposite way around. Is there a particular reason why you did this? Did you A/B test it?


I've done this before. When I did it it was a conscious design decision to use price framing[1], so the site has a very expensive product, two mid-priced products, and a free product. It's nice when the very expensive product sells, but it's mostly there to make the two non-free products look like reasonable purchases.

I haven't A/B tested it, that's something I should do.

[1]https://www.psychologytoday.com/blog/the-decision-lab/201109...


Awesome idea. Would be great to see some test results, once you test it.


I'll try to remember to test, then I'll try to remember to post results ;)

It'll also be interesting to see drop-off at that point in the funnel - my signup form is a bit of a monster.


Good question. Never A/B tested (!) but there was some intuition about leading with the most expensive option. Perhaps to make the others seem more reasonable in comparison.

In any case, we're changing this very soon to list from left to right including the Free plan in the table (I don't like that it's hidden beneath the paid options).


I'd like to thank you for creating your API, and for the generous terms on the free plan. I'm using your API to estimate my weekly revenue (internal reporting).

A suggestion: It would be awesome if it was possible to download historic data in batch format (eg. CSV) which would make it easy to copy the data into my reporting database. When I started working on my own reporting solution, I'd have paid $100 just to download a CSV file with 5 years of exchange rates, even though the data is available for free on a bunch of websites, since it's such a hassle to collect.


The Bank of Canada have downloads (CSV, RSS) for historical rates http://www.bankofcanada.ca/rates/exchange/ - you may need to convert to eg USD rates but the data is easily accessible.


Thanks and you're welcome! We do have a time-series bulk download, but it's still in JSON format and currently limited to 1 month of data. This will be redesigned soon and looking to include CSV downloads as an option.


Welcome!

We do have a time-series bulk download, but it's still in JSON format and currently limited to 1 month of data. This will be redesigned soon and looking to include CSV downloads as an option.


Github asked you to take down a hosted repo because it was too popular? I'm slightly shocked at that (just a tiny bit)


It isn't shocking at all in this context - GitHub is for hosting code (and other code-like things), it isn't a content delivery network.


I would guess because Github was not being used as a code repo, but was essentially being used as free CDN for the data file. I've seen direct linking to Github raw files like that before and wondered if it was something they condone.


Yep. GitHub were cool about it, explained that some people were making thousands of requests per second for no reason at all and it was impacting others users on the network. It's not the intended use of GitHub at all and I genuinely had no idea it would become popular.


Are your top customers really only paying you $97/month? Seems like you could charge them substantially more money.


Isn't that stretching it a bit too much? It's a service that can be replicated for free with the Yahoo! Finance APIs and a couple hours of your time.


Yahoo finance APIs are notoriously finicky. They go down. They change. Hard to build a business off that.


I can't say I can relate, I've been using them for two years without an issue.


Great Saas , can you tell from where you poll the currency data ?


Wow, I was looking for something like your project for months!


Yeah, so looking at the GitHub Cabal's secret price list, 25,000 GH stars will put you at $102k / yr, so shoot for that.

Seriously though, the fact that you're asking about GitHub stars is... telling. There's plenty of popular repo's on GitHub that I'd refuse to pay any money to, but more to the point, GitHub is a terrible customer experience because it's not for selling software to people, thus the only thing 'GH stars' tells us is... the number of people that have starred a particular repo.

For a purely open-source project, look at OpenSSL. It's probably in production in a significant amount of the entire internet. But until Heartbleed came along and it came to light that the OpenSSL project was severely underfunded, it was limping along with little sponsorship.

Red Hat is probably the most famous open source business, but unfortunately, if you look at their practices, they're abiding by the letter of the GPL, but not entirely the spirit, which they've decided is necessary from a business perspective, so if you're looking to make a lifestyle business based on your open-source project, the question to you is: how comfortable would you be with a lifestyle business based on an entirely proprietary project?

Is this a pipe dream? Chances are, yeah. But do dreams come true? Sometimes :)


I now regret choosing to bring up GH stars (was just grasping for some concrete indicator).

I was more trying to start a conversation, which succeeded.


It's completely feasible, but you're playing on hard mode when you keep the software open source. If you've got good business sense and are willing to hustle you'll find a way to succeed. If your only strong suit is software, however, you're setting yourself up for failure.

Would you rather make $300k a year writing and selling proprietary software or fail/make $20k a year providing value-added services for an open-source project? This isn't a tough choice for me, but for some people the ideal of open source trumps all.

It's much easier to write software that fits a simple business model, than to figure out how to shoehorn a business model onto an open source project. You can tell which route is the pragmatic one: start from scratch, optimize for easy monetization.

That said, don't let any of this discourage you. It's absolutely possible to create a cool lifestyle business based on an open source project (or anything really). The only way to know if you can do this is to seriously commit to it. If you don't have to support a family it's probably a risk you can take.


> for some people the ideal of open source trumps all.

You said it as if its a bad thing.


It's neither good nor bad. It's just a preference and/or philosophy.


Thank you for your input, it's sobering, yet encouraging :).

> It's much easier to write software that fits a simple business model

Everyone talks about this, but how do I find this business model? Is there some methodical way to uncover needed software?

I mean, everyone talks about having industry expertise, but I actually do have industry expertise in a non-software-related industry (I only returned to software development after a 10+ year hiatus). But my industry expertise is worthless for this particular task, since this industry is absolutely flooded with software, mostly low quality but also some high quality stuff. The last thing people in the industry need is another software package (and they even say this).

So how do I find these vaunted "business models" for paid software?


A business model isn't a unicorn. Your business model doesn't need to be unique or even different. To the contrary: just do what's known to work!

90% of software companies have the following business model:

    * create proprietary software
    * charge money for licences
    * charge extra for support
    * charge extra for updates
    * pay through the nose for enterprise options
90% of saas companies work like this:

    * create proprietary software
    * offer a free trial
    * charge money for it every month
    * (optional) pay through the nose for enterprise options
It's just that simple. No need to overthink it.

Having industry expertise just makes it easier to get to product-market fit. It's by no means a requirement. You may be undervaluing your industry experience. Unless your market knowledge is really generic (e.g. webshops), you've probably got some valuable insights.

(edit: most programmers get paid well, therefore, if you become a programmer you're likely to get paid well. If there are a lot of companies making money in a market, then you're likely to make a lot of money if you enter that market. Inversely, if everybody in a market is struggling [indie games] then you're likely to struggle too.)


In the case of the SaaS business models, is the first step even needed? I'm still trying to not be blinded by my idealism but is there really any value in making source proprietary if it's a SaaS business? Would GitHub's popularity be affected appreciably if it were closed? Google's?

I remain hopeful that the standard SaaS business model dovetails nicely with free and open source software.


Google's certainly would be. Microsoft has dumped millions into trying to get Bing to a point where it can even begin to compete with Google—if Google open sourced their code, tons of competitors would crop up trying to take market share.

GitHub would probably have less of a problem with open sourcing their code because their primary value prop isn't that they've built some brilliant software but that they take the bother out of managing your source hosting.


> GitHub would probably have less of a problem with open sourcing their code because their primary value prop isn't that they've built some brilliant software but that they take the bother out of managing your source hosting.

GitHub is making money by selling their proprietary pack to other corporations so they could implement it on their own server. If they release it for free, they wouldn't be able to support free code hosting services and remain profitable.

They're also selling premium plans for the regular users, but I don't think that this gives them enough profit to remain profitable.


The facts point squarely in one direction, as far as I can tell. Profitable SaaS companies are proprietary. Where are the billion dollar open source SaaS companies? I don't see them. Maybe the big companies occasionally release a component on github to get some goodwill, but nothing big.

It's only when you go all the way down to the "lifestyle" sized companies that I see real dedication to the open source ideals. They're willing to put their entire product on github. Props to those founders, but it's pretty insignificant because those businesses are so small.

Most people don't have the skills to run their own servers, and nor can we expect them to. Service based products are the future, but I hope that interoperability gets to the point where customers can switch painlessly between different providers. That would put a lot of leverage back in the hands of the end user. If I had to name one problem it would be lock-in, not proprietary code.


No, I maintain that for SaaS, that first step is not needed. There can be tremendous value in finding an OSS project and basing a SaaS business on it. The most important thing is still the value it offers to your customers.


this...


> Is there some methodical way to uncover needed software?

I think this is a common thread here - software developers looking for a problem to solve. A lot of people invent a solution without really knowing whether it is a problem - or is the main problem for whatever industry it's serving.

I personally feel like you'll always do better if you at least have a passing interesting in whatever business you are planning to "disrupt". If you don't work in the industry itself, then it's probably a good idea to have a partner who does and can bring to the table the deep understanding of the industry and whatever pain it may have.

Finding that is not incredibly difficult - there are thousands of people who have an idea for an application and are looking for somebody to bring it to life. If you don't personally have any inspiration for an idea, then you can always find somebody who has the idea and industry experience and create a great team.

Another reason for having such a person is that, even if you write an amazing app, you'll quickly find that each industry can be a small world, and the vendors you are competing against are already having lunch and playing golf with the major buyers in that market. If you have no connections at all, it can be extremely difficult to get your foot in the door. "Build it and they will come" is not something that is usually true.


Here's a list of revenue and business models for online companies. I have this list to be exhaustive:

https://hackpad.com/Web-And-Mobile-Revenue-Models-final-EgXu...


Thanks!


> Everyone talks about this, but how do I find this business model? Is there some methodical way to uncover needed software? I like traction's bulls-eye-framework approach here.

> since this industry is absolutely flooded with software, mostly low quality but also some high quality stuff. The last thing people in the industry need is another software package (and they even say this).

I don't know about industry, but perhaps, there's a lot of software with bad User Mental model/User Experience??. In any case, it sounds like the industry could use some disruption based on clear feature reduction, support and UX improvements(your experience should point to which it is).


You need to find a few things: an area that has need of better software, preferably one which isn't overrun by competition, and then take a different approach than everyone else.

I just posted about our approach here: https://news.ycombinator.com/item?id=9788772


Well of course if the software is mostly low quality everyone will say they don't need more of it. Who wants more crappier crap?

Find out why they think it's low quality and do a better job on those points. That alone can be a major selling point of your software.


I've always thought that open source or freemium was an equalizer to get found by potential users on the net. If you lack the capital and/or marketing chops it's a valid alternative.

It hasn't been said but I suspect it wouldn't work nearly as well for a consumer product than it would for something targeting businesses.


Making money with software is not very correlated with said software's quality - or popularity. I think yours is an unanswerable question, you should probably start from the other side of the equation (i.e. what's the target marget? who would be willing to pay for the software? and, given that we are talking about open source, what would you sell - and to whom - to beat the possibility to just use it? What would the licensing options for commercial usage look like?).


Here comes the unpopular opinion: I don't like open-source projects being "turned into a business" at all. Something's always gotta give.

* Paid support: you now have an incentive against improving the documentation. Conflict of interest.

* Selling binary builds: your software can no longer be easily recommended and shared by others.

* "Premium features": I'd rather call this 'crippleware'. You're intentionally crippling the 'community version' to give people an incentive to pay you money. That's certainly not in the spirit of open-source.

Frankly, I don't feel software is a thing that should be sold at all. You're always going to be intentionally (and artificially) restricting something to make that business model work - after all, software is infinitely reproducible at effectively zero cost.

Instead, if you absolutely must make a business out of it, offer something like a hosted service (that people can easily replicate themselves, in the spirit of open-source). That way you add something to be sold, rather than taking something from the existing project and asking money for it.

The better option is to accept donations, and put some serious effort into getting those going. I don't really understand why people will spend weeks drawing up a business plan, but for donations they just slap a 'donate' link in the footer of the page without thinking, and then complain after a few months that they're barely getting any donations. Accepting donations requires the same amount of thought to make it work.

EDIT: No bulletpoint lists on HN? :|


There are ways to introduce a paid layer of services above and beyond the basic product without needing to lock away features of the software itself as you said, though. Things like cloud-based services that cost you money to offer. I'm working on this now for one of my projects that has quite a bit of debt in my name for the first several years of hosting when it was more expensive for hosting and bandwidth.

While donations may be preferable, one unfortunate thing is that while donations and advertising on your hosted site can add up and can pay for hosting and a few niceties in some cases, they often don't bring in enough to support even a single developer. Or pay off back debt in my case.

Many open source projects wind up abandoned due to the developer(s)' inability to make ends meet from the work they are doing. Real life responsibilities... job, college debt, family, etc... tend to pull in the other direction. Many open source and freeware apps in the Windows world are turning to less-preferable means of supporting themselves such as bundleware. In the mobile world, they're trying their hand with more intrusive in-app advertising and in-app purchases.


Unpopular but not unreasonable.

- software is a new form of literacy. Perhaps at some point in the past literate people could contribute to the communi

- the fallacy of altruism. Developers working on an open source JS drop list widget are not being altruistic - their contribution to the community could as easily be say working at a soup kitchen, probably with more value to the world.

"Contributing to the community" is something we rely on Adam Smiths Invisible Hand to help us with 99% of the time. So while I use and appreciate the OSS developed to date, it has gone beyond a simple charitable model and into an Eco-system beyond any simplistic approaches. I would like nirvana, but it's dubious as a long term strategy for OSS.

- conflicts of interest always happen. When it is important enough, say Linus' salary, the community will either whither or find a way to build its own institutions to make the important conflicts managed - like Linus salary. This is part of building strong institutions we hear about so often

- getting better at begging vs better at selling seems to be the last point you make. Honestly I cannot see that as a honourable position of trade.

We don't have perfect solutions - but we are working on them


> getting better at begging vs better at selling seems to be the last point you make. Honestly I cannot see that as a honourable position of trade.

Asking for donations is most certainly not begging, and I personally find that a somewhat offensive way to present it.

Donations are a voluntary contribution in return for some kind of work that was done; begging, by definition, isn't in return for anything. They are two fundamentally different concepts, just as different as 'accepting donations' versus 'selling'.


Ok - sponsorship.

Donations is to my mind a charitable endeavour - the small amount of change is thrown over and not considered. In fact lack of consideration is probably the right legal term. Sponsorship involves some contractural form to occur - and so implies a trade of value.

To be fair you could have been saying get better at donations by rebranding them as sponsorship instead of better at soliciting uncontracted contributions.

But I still think we need to find a new and better way to monetise OSS contributions.


You would never know unless you started exploring. Stars have nothing to do with revenue - it's purely a function of how much value you can add to the enterprise. Basically, you have to demonstrate quantitatively that you can charge $X to help them save $Y where Y >> X.

Here's what I would suggest. Reach out to a few people from these organizations and ask them for their general views on your project and what their major pain points are. I'm sure they will be more than happy to talk to you about it if they're indeed already deriving great value from it. Once you have established a good rapport (i.e. warming up the lead), set-up a call with them to pitch your vision for the paid product. A call is crucial because email and text can only communicate so much - you can get a far better idea of their domain and problems through a quick 45 min call. Scheduling this should not be a major problem once you have established a good email channel previously.

If you can get about 8-10 people interested in exploring your paid offering you have something that's promising. After that you can think about scaling the business with self-service etc.


I hate phone calls, but I suspect you're right about this. But calling potential customers is definitely concrete advice I can do.

BTW, everyone discounts Github stars, but the one thing stars gives me is a very easy-to-access list of potential customers.


Great attitude! Making these phone calls is like building up a muscle. It will become easier, I promise. And I think you'll be surprised at how pleasant many of them will be. My best to you.


Sell your expertise as an integration/support engineer to companies who want to use your project but don't want to dedicate the internal staff time to become experts on same.

Every company that emails you asking you for help is a sales lead. "I'm happy to implement/configure this for you. I charge $X per hour, and what you're asking for is about Y hours of labor." To the client, X*Y is often cheaper than the opportunity cost of pulling an engineer away from other work. Also, don't be afraid to make X >> $100 if nobody else offers the same expertise.

You can do as much of this as you want, without changing anything about how the software is licensed or packaged.


There are a few podcasts that have discussed this. Typically it is done via support for existing OSS, offered to companies who need to be able to depend on full knowledge & stability of that code. A couple of examples:

1) Redhat

2) "some guy" from one of the podcasts I can't think of at the moment who forks Ruby and keeps a stable, supported version for his corporate clients, while dealing with patches & upgrades on his own to his fork

In both of these cases, you can see that is isn't actually "how many users", but "how many corporate users who need a service that keeps software X completely stable and managed"

So I think from what you've said that it would be a good thing to look into. You may want to contact the guys from http://www.tropicalmba.com/ for a few pointers - this is right up their ally and they are very willing to discuss


RailsLTS (https://railslts.com/) is probably the product you're referring to in (2).


I manage a small open source project (https://github.com/frappe/erpnext) that churns 100+k per year and helps me manage a small team. It took me 4-5 years to reach here. We make money by providing hosting and also help to other developers working on our platform.

I would start with a services plan and a beautiful website. If you are not a designer, do hire one. Good design and quality can go a very long way towards achieving your dream.

If your project is an app, you can also go the SAAS (softare-as-a-service) way. But beware, building a multi-tenant platform, and working on user onboarding, marketing your site can be 2x to 3x of your original project your project.

The good thing is that once you are there, 1/2 years is a reasonable time, this will only grow.


Yes, it is definitely realistic. We've seen several projects like Sidekiq (http://sidekiq.org/) that did it.

Another quantitative indicator you can use is number of downloads on relevant package manager (npm, PyPi etc.). These indicators only tell you how big your audience is and not whether your project could provide income. However, having big audience increase chances of success - you have a good position here.

Check out MinoHubs (https://www.minohubs.com). We provide tools that will help you get started with monetizing your project in several ways very quickly. Let us know if you have any questions or if you're missing anything.


It is less about how many stars you have an more about how many enterprises use your software. GitLab has 15k stars on GitHub (we moved the canonical source to GitLab itself a while ago) and more than 100k organizations are using it. But most of our income is coming from larger enterprises in the United States. It you can offer them extra features and market it properly you can expect something like 1% of your users to sign up for a paid plan. Please let me know if you have any questions.


There is no sustainable way to monetize an open source project, except to offer a "premium" service (which, unless you are comparable to Redhat by market cap will probably unprofitable - I think Orable is losing money on MySQL) or you offer closed source "enterprises" version, like so many do, but it must be an exceptional tool, like nginx, varnish or nessus.

So I am very sceptical about monetization of community-driven momentum (the moment you close the code it begins to stagnate and die). Unless you are leader in your niche the chances for earning living from a project are close to zero.

Wordpress or other themes is a different kind of offer.


I have had a few open source projects with around 250k installs (web apps and Wordpress plugins). One of them I was able to monetize for about $1k per month. I was getting inundated with support requests so finally I created a "product" by putting up a "buy now" button for $250 installation support. I then ran some google ads to promote it. This was an encryption product so it had business users.

If you make it easy for people to give you money and you have a useful product then there usually will be a small percentage of users who will pay. But I'm a firm believer that to make money you have to put effort into sales.


Pipe dream.

a) 100k / year is not 'reasonable', it's huge in microisv terms. The modal revenue for independent software vendors is $0 (stats from payment processors). To get there in 2 years is even less common.

b) The number of 'stars' has correlation r=0 with ability to monetize. I'd even speculate - the more stars, the more ingrained in people's heads it is 'this is open source, ergo free', the harder it will be to make money. If you're selling support for something only slightly popular, customers will have no other options - but on support for Wordpress, you have to compete with other devs, with 2$/hour rentacoder people, with Amazon selling 'teach yourself Wordpress in 60 minutes' books etc.

c) What incentive do companies have to pay for it? You have to be able to articulate it clearly before going down this path. Your wording makes me think you are thinking 'this is my secret sauce, I can't give it away', which is (frankly) very naive. If your idea is even a little bit good, you'll have to stuff it down people's throats to accept it. I don't know of any business that makes money OS software (on the software itself, not the consultancy around it) without having a dual licensing model - GPL or commercial. And if that was really a cash cow, Trolltech wouldn't have been sold a dozen times (or so) over the last 10 years...

To judge whether your product has commercial potential, you need to

1) Describe your customers. In detail. Not just 'anyone using a database', but 'medium scale accounting businesses with on-premises case database' (idiotic example, of course). You need to do this in such a way that you can derive a strategy from it on how to find them. E.g., accountants meet at industry events, where you could book a booth.

2) Identify a sample of, say, 100 of them, using the methods from step 1.

3) Start calling them. Preferably after you've taken a sales class (just 2 days will give you life changing insights, I promise). Not emailing, actually talking to people. For the 100 from step 2, identify how many would buy your product.

4) Get sales promises, 10 or 15 or so. People who you can excite so much about your product that they promise (informally) 'yes, I'll buy this if you offer it within 6 months' or whatever.

5) If you can't even do this, you have no (OK, 'barely any') hope of succeeding.

The main skill you need is marketing to succeed at an endeavor like this. The quality of your software, or its popularity amongst the crowd that uses Github, is of secondary importance at best. That's not to say that you can succeed with selling people crap product, snakeoil style, just that your life as a software vendor is 10 or 20% of software development, at best (or worst, depending on your perspective...)


Thank you, this is invaluable.

BTW, no "secret sauce", just lack of willingness to submit the question in my real name at this point in the game for several reasons (current employment status, etc).


Any particular sales class/course you'd recommend?


No, I took one from a local small firm, I didn't arrange it so I didn't do much research on it. I think the stuff we covered was so basic that anyone in sales would go facepalm on how basic it was, and yet for us (room full of engineers) it was so outside of what anyone of us knew, that it was one new insight after the other. Also, it did a lot of role playing exercises, which I find awkward but useful. I don't think it matter much which course somebody at my level (0 sales skills) would take. It's similar to any high school teacher being able to explain a linear function - you don't need a maths PhD for that.


I have a little over 1000 stars (1044 at time of post) and have made $10 in Bitcoin (Which is worth less than $10 now). That being said, my project is extremely-side-projecty[1].

Others have discussed busies models, so it should be a simple calculation of how much you can charge for a model vs how much it will cost you to run your business and if you can live with the reminder after taxes etc... then I would say do it.

[1] - https://github.com/joeblau/gitignore.io


Just have to say, thank you very much for creating this. Use it every for every single new repo I setup, saves loads of time. It's just awesome!


It looks like a very useful project that I will probably start using. Sadly, my usual workflow for gitignores is to grab one from a previous project of mine and adapt, or else Google a big project I know in the language I'm targeting, grab from there, and make a few adjustments. Your process looks much more efficient.

But how did you even make $10 in Bitcoins? I don't even see a donation link or address, much less a place to sign up for a paid plan.

I see a lot of potential, for example, you could expand a premium plan to include other project templates, like maybe travis.yaml, and the various .jshintrc and other ....rc's, perhaps). I'd pay $10/year for that, maybe more depending on how well it was done.

Or perhaps if it's just a side project you're not really interested in expanding.

Also, Bitcoin just realistically, Bitcoin isn't used by a lot of people, even in the developer community. It's great to include it as an add-on, but I'd think if you want to make money, you need to accept USD.


Bookmarked this. This looks seriously useful (has vim support!).


1 star. If you are starred by a big tech biz and they are willing to finance you up to $250k/year (or maybe a million per year?) to keep the project running and clean bugs by the very own creator of the project. Because your project is handling infrastructure for them that runs a multi-million dollars business.

100,000 star. If you are starred by your average to not-so-average (high or low) developer. There is no clear monentization plan. But given the popularity, ads and affiliates might bring you $1 per star (assuming a star is 40-50 visits/year).

Think about it. You have a bridge between Queens and Manhattan. I'm sure the US, NYC and people are willing to finance, pay you, or buy you. For what-ever big price (might be unreasonable too, to the cost of creation) you ask.

But if you have a bridge between Antarctica and the French Southern Antarctic lands (just randomly picked), it'll be certainly an amazing and well-known artefact but I'm not sure how you are going to finance it (especially that Tourism is not huge there).


In regards to the GitHub stars, I don't think that a high amount of stars actually correlates to the amount of people using the repository.

Cachet (https://github.com/cachethq/cachet) has 2.6k stars but I know that the amount of installs is actually far higher.


Fair enough, and to be clear, I'm nowhere near 2.6k stars, although the project has grown quickly with no promotion.

The only reason I pulled that particular indicator out of the hat was to provide some reasonable benchmark for comparison.

But perhaps it was not a reasonable benchmark, after all.


I would think merged pull-request (aka community patches that doesn't suck) would be a better indicator on gh - at least for open source project. Fixed issues a close second.


Linux and LLVM have no merged pull requests on Github. And a lot of these "Awesome x" (Node.js, Rust, Go, React, etc) will merge just about anything.

Also, I know of several project that fix tons of issues, but are relatively unpopular (perhaps because they have so many issues?).

I think the bottom line is there are no perfect indicators of open source project popularity.


Linux has lots of merged patches though. That they don't have merged prs isn't surprising as they handle patches via email.


Our project has 295 stars and 1+ million installs. Stars is definitely not a reliable indicator.


Don't know how common it is but I for one use the starring function to tag projects that I'm not using! This is so I've got a note of it to look at later.

For projects I'm actively using, I'll either have a fork, or just a clone of the repo locally.


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.

Best of luck!


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]

So again, best of luck :-)


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.

More at http://scoop.sh


Thank you, really good advice in there, particularly the emotional aspects of this kind of pursuit (ie, pissing lots of people off).


As others have said, the number of stars is irrelevant. The most important factor for success is not the popularity of your project, but the problem it solves, and whether there's a way to monetize it.

I started making money in 2011 with a GUI for an open source command line tool. The open source software was available completely for free, but compiling it was a hassle, using it was annoying because of a few serious bugs, and you had to use it from the command line.

I made money by making an existing, free tool available to people who didn't want to use the command line or compile their own software. I charged a modest fee (initially just $5), and people gladly bought my app to solve their problem. Nobody cared about the fact that it was open source and they could have solved their problem for free; they just considered my app a fair deal.

(I still sell this app, MDB Viewer for Mac, but I've since completely rewritten the open source library it depended on)


You've made fantastic steps towards making money from your project. It's use in production shows that it has business value.

http://nathanbarry.com/authority/

I think Nathan's book describes an excellent outline for success in this regard. Basically you can look into "tiers". You give away "free" resources. Blog posts and the liberally licensed open source software itself. You can also paid resources. A book, perhaps screencasts that accompany the book for a premium price. Workshops and onsite training provide another tier. At the very top is consulting at ultra-premium rates.

This is oversimplified, but this is the idea. The "free" stuff is critical, and builds the basis and "proof" for the paid offerings.


It really depends on what the software does. I've mostly seen people make money off of their open source software by consulting for companies that use it. For example, I know a couple companies paid the creator of core.typed to develop it further. But those were one off gigs, not recurring revenue.


When you get the hype, for example front page of HN, that would probably be a good indicator that it should be possible to make a living on it. It doesn't even have to be your own project :P

There are excellent comments in this thread btw. I've bookmarked it.


What's your "good way to monetize it"? The typical approach I have seen is selling support (paid custom features or forks) but that doesn't scale well. You'll basically be a freelancer specializing in the project you wrote.


Note that he wants to create a lifestyle business, not a startup. Not sure how important scalability is for that.


Selling related software that works in a different environment (say, mobile, or resource-constrained, or a different OS).

Yeah, I've already done your second approach, that's not what I'm hoping for (which may prove elusive).


One star, if it's from the right person.

Revenue is number of people willing to pay you time the amount they're willing to part with. Neither of those can be inferred from number of stars on a GitHub page (it probably has the most correlation with the number of people willing to pay, but there's going to be a scaling factor there that will vary dramatically based on the nature of the project).


If the project is popular because it's a free alternative to something that costs then I imagine charging would kill it completely.


Is your goal to be paid to write your software? Have you considered looking for a job where you would be paid to develop this software by a company that needs it?

How do you envision your open source lifestyle business once it is up and running? (do you want to be paid to develop software or are you hoping to make a business that "runs itself"?)


Does your landlord or local supermarket accept stars on github as payment?

There's your answer

You need to provide a service connected to your project, this is regardless of how many people use your project.


My local supermarket does! It's called GitPay. I just provide my github username at checkout and they deduct starts from my repositories. The exchange rate is roughly 10 euro per 26.2 stars. I generally get better rates at the bank by the convenience of GitPay has made it hard to resist.



My question for those that have spent years building a product:

Was it worth it open sourcing your product?

Did you get lot more leads and exposure?

I'm afraid of open sourcing because I'm not sure if it will do anything for me, and that I'm giving away years of work away for free.


I think working on open source, both unpaid and paid, projects definitely has been worth it for me professionally. Independent of self gratification and such (rather important IMO), it has lead to offers for interesting jobs and by that increased what kind of remuneration I could get. Above what I think the additional years of experience themselves would incur.

I think it's harder to answer that on the angle of open sourcing projects. I've, together with colleagues, spent the last few years doing paid for feature development for an open source projects. It's possible to have a company around that and support, and grow. But it's not easy.

My impression, more from the side lines, being a technical person occasionally involved in sales, is that it help in lead generation, but that the conversion ratio tends to be lower than with leads for a closed product.


>My impression, more from the side lines, being a technical person occasionally involved in sales, is that it help in lead generation, but that the conversion ratio tends to be lower than with leads for a closed product.

This is what I'm seeing. Even when I had free trials, vast majority of people were just free loaders, some even going as far as using a prepaid card to get past the requirement.

Which is why I'm hesitant to jump on the Open source wagon, I don't want an army of freeloaders now demanding and whining, like I see all the time on github.


On the other hand lead generation is cheaper...

I think it's hard to answer you questions without more information about the type of product. My impression is that plays a large role in viability. ISTM infrastructure type pieces have a bigger chance to open source successfully.




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

Search: