Software needs popularity. Generally if too few people are using a thing, it’s not worth improving or even maintaining.
This applies to open sourc...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
True enough - being a hosted language means there's a nice clean buffer between the dev and the platform
Agreed. Consider:
and
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.
One may be the loneliest number, but it's also the required number of users for a piece of software to be 'alive'.
I have plenty of softwares that only I use, and yet they are completely worth improving and even maintaining.
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.
Amen!
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.
I built a DigitalOcean library for myself:
JavaScript library for the DigitalOcean API
DigitalOcean JS
JavaScript library for the DigitalOcean API. For use in Node or the browser.
Goals
This library was built with a few goals in mind:
async/await.Usage
To use the library, install from the npm repository.
$ npm install --save digitalocean-js # Alternatively install with yarn $ yarn add digitalocean-jsSimply import the client and initialize it with your 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! :)
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.
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.
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.
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.
tl;dr
Popularity is an indicator but not always the best metric to evaluate software.
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.
That makes a lot of sense.
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.
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.
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.