How much popularity does a software project need?

ben profile image Ben Halpern ・1 min read

Software needs popularity. Generally if too few people are using a thing, it’s not worth improving or even maintaining.

This applies to open source libraries but also software in general.

How much popularity do things need? Often we lean in on big projects because they’re popular and therefore “won’t die”, but do things need to be massively popular to live?


Editor guide
deciduously profile image
Ben Lovy

A counter-example I've noticed to the instinct of gravitating towards tools with huge amounts of ongoing activity is with Clojure and Common Lisp libraries. A lot of the times these will simply be "done" - there are libraries getting used regularly today that haven't seen a single commit in years because they cover all use cases as expected already. It's a little weird to go to a useful library's repo and notice it looks "dead" for all intents and purposes, when really it's just a completed solution. With JS framework churn taking so much mindshare and generating so many headlines it can feel like software that's only a few years old is already horrendously out of date, but this couldn't be further from the truth.

cjbrooks12 profile image
Casey Brooks

There is a lot to be said for projects that actually achieve "done". A lot of projects will keep adding features and bloat so that it diverges from its original goal, and others will just be abandoned in a buggy state. But a project that's actually "complete" is really hard to achieve and is a sign of a well-made and high-quality library.

As an example, I recently adopted thumbnailator for basic image manipulation in Java, even though it hasn't received an update in years. But every indication I found shows that the product is fully mature and complete, even with the author stating that he is not accepting PRs anymore! And I have no heartburn about adopting this "older" technology at all.

david_j_eddy profile image
David J Eddy

Agreed. I find that as projects mature the drive to add bloat or the desire to 'cover every use case as a first class use case' is detrimental to the library, the language, and the community. Projects can be 'done' just like any physical project.

ben profile image
Ben Halpern Author

Yeah, this is a really great point. A lot of the JS struggles have to do with how tightly they couple to the browser or whatever platform they run on, which will change out from under them.

deciduously profile image
Ben Lovy

True enough - being a hosted language means there's a nice clean buffer between the dev and the platform

samipietikainen profile image
Sami Pietikäinen

This reminded me of a blog post I read recently about The Source History of Cat Linux command. The first version was written in the late sixties and the current version has not changed in years. Yet, it remains useful year after year.

dangolant profile image
Daniel Golant

This is a good point, but I think "done" is a state of minor change as opposed to no change. Dependencies will always update and break, vulns will pop up, etc.

gypsydave5 profile image
David Wickes

Agreed. Consider:


jerodsanto profile image
Jerod Santo

One may be the loneliest number, but it's also the required number of users for a piece of software to be 'alive'.

Generally if too few people are using a thing, it’s not worth improving or even maintaining.

I have plenty of softwares that only I use, and yet they are completely worth improving and even maintaining.

moimikey profile image
Michael Scott Hertzberg

I wouldn't say popularity matters. It's a dedicated maintainer that matters. A project could have practically no following but is actively maintained by someone dedicated and smart and is passionate about their project. I wouldn't stop a project because it's not popular enough. I think popularity comes from whether or not the project suits a large majority of people and gains its popularity through that. It also helps to have a known name behind you... if you're a known name, you get 1000 stars in the drop of a hat and the project could be about dolphins.

david_j_eddy profile image
flaque profile image
Evan Conrad

Software dies when it's no longer worked on. For example, take 🔮Samba.🔮

Have you heard of Samba? If you're answered "no," you're like 100% of the population.

Samba is an open source Server Message Block networking protocol server built in 19 freakin' 92. That's 26 years ago. Samba is as old as the country of Bosnia.

What's a Server Message Block (SMB) protocol? No idea. Why do you need an SMB server? Reasons. Who made it? Old people.

But you know what? Samba's last release was 13 days ago. It's still actively maintained, runs on more operating systems than you've heard of and comes standard on most flavors of linux.

That project is a testament to the obscure. It's a miracle that those developers are able to survive the thanksgiving questions from their family: "What do you do?"

So does software die when it's not popular? No probably not. Does it die when few people are using it? Still no.

Software dies when you stop working on it.

johnbwoodruff profile image
John Woodruff

I built a DigitalOcean library for myself:

GitHub logo johnbwoodruff / digitalocean-js

JavaScript library for the DigitalOcean API

DigitalOcean JS

Build Status npm npm npm

JavaScript library for the DigitalOcean API. For use in Node or the browser.


This library was built with a few goals in mind:

  • Be able to use in a Node or Browser environment with no difference in usage.
  • Use Promises instead of callbacks so clients can make use of async/await.
  • Be built in TypeScript so consumers of the library can benefit from excellent intellisense with the TypeScript definitions.
  • Provide solid documentation including examples for usage.


To use the library, install from the npm repository.

$ npm install --save digitalocean-js
# Alternatively install with yarn
$ yarn add digitalocean-js

Simply import the client and initialize it with your API token:

import { DigitalOcean } from 'digitalocean-js';

const client = new DigitalOcean('my-api-token');

To see all the services available, check out the documentation.

From what I can tell I'm still the only one using it. But it's exactly what I need for a project, so I continue to maintain it for me! :)

rrampage profile image
Raunak Ramakrishnan

Software use and development is always a battle between "the new shiny thing" and "if it ain't broke, don't fix it". As long as there exist people in the latter camp who have adopted the software, it can not die.

How much popularity do things need?

Just a small community willing to make it better and keep it running. Once a critical mass of users is reached, projects will not die. They may become less visible to mainstream but they will continue to survive.

As an example, look at programming languages. Lua, C (was much more popular before), Haskell, Clojure will not win any popularity contests. But they are popular in their niches.

thomasjunkos profile image
Thomas Junkツ

No. Software doesn't need to be popular. Software is written for a purpose - to solve some kind of (business) problem. As long as it serves the purpose it will be used and maintained. If the cost of maintaining is higher than the expected return value it will be dismissed. I think the number of users is one variable in this calculation, but not the only one.

The notion of software being popular or constantly evolving or even building a community is a very recent development in our industry.

If you are doing business, using "popular" software helps in risk assessments:

  • the problems you are having with a piece of software were perhaps already solved by others

  • if it is "mainstream" enough, you could easily throw people at your business problem

  • if the software is open source, every patch which goes upstream will not only help others, but will be maintained for you in future versions

OTOH choosing software by "popularity" has the risk of making the wrong choice: perhaps the solution is popular but for your usecase overly complex.


Popularity is an indicator but not always the best metric to evaluate software.

dangolant profile image
Daniel Golant

Just had this discussion with @milkstarz . I think this is an important question because if you're a person who wants to build things, you still only have X hours in the day to do it. My answer is loose, but it's the point at which someone from the intended audience starts actively giving helpful feedback, offering to help, suggesting features, etc. If you get even 1 person with that much buy in, I think they become an advocate for your thing.

dfockler profile image
Dan Fockler

I think you need a caveat, 'large, complex' projects need popularity to survive. There are thousands of small gems, and packages that are high quality that people use that are mostly feature complete. Large projects have a larger surface area in which bugs can occur and need constant maintenance and new work to be sustainable and valuable in the ecosystem. If a project falls out of scope with how people work or it's bugs linger too long, people will move on.

moopet profile image
Ben Sinclair

Popularity is a measure of popularity, nothing more. It's like the old "10 million people can't be wrong" line.

If popularity was a metric of success, free software pretty much wouldn't exist. There would be no reason to ever start writing anything, ever.

alex_barashkov profile image
Alex Barashkov

My life position is that build something useful for yourself and if someone else will find it useful too - it's just a great bonus. In that case it's not necessary to have a very popular project to stay it alive.

So there are different projects which differently will rely on popularity. If you build ambitious, modern and massive project, which requires community to be a part of it(such as dev.to), you have to worry about popularity. Especially it's hard at the beginning to grow the community from scratch and engage more people. And it could be a different project - small one. With my team we developed one really small Mac Os open source app around year ago, thousands of people use it, but we do not have contributors at all(also because it's probably swift language) and also because it's just one action tool, it just works.

ben profile image
Ben Halpern Author

That makes a lot of sense.

alanmbarr profile image
Alan Barr

My main thing for any large enough project is community. If it is a one off tool that is feature complete i'm not concerned. However, anything that is sizeable I just want to know I can find stuff on stack overflow or resources. Sometimes a solution is technologically better but with no community I prefer something inferior. I get this sense in VHS vs betamax or WCF vs restful/rpc http and now Kubernetes vs Service Fabric. Not that all of these are direct competitors but a giant community of free resources is hard to compete against a gaping void.