4 ms·

Indeed, popularity does not directly correlate with quality (which is not to say that popular libraries and tools are never high quality.) That said, the reason

Indeed, popularity does not directly correlate with quality (which is not to say that popular libraries and tools are never high quality.) That said, the reasons most projects fail have less to do with the imperfections of the tools used than with the approach taken to the project as a whole. And especially if you're running a business there are good reasons to choose tools that are reasonably well known and widely used, regardless of whether they're the absolute best available on the market. The biggest reason being that it's a lot easier to find developers who know or are interested in learning a popular tool than an obscure one.

CJefferson 12y ago
I agree entirely. Long ago, I got some amazing advice, which has helped me to this day. "When you have n choices, and you aren't positive which to choose, choose the more popular one". I used to think this advice was about "the more popular is better". Now I don't think that's true. But the more popular is (in the case of software for example) more likely to be tested on more OSes, or have questions with good answers on stackexchange, have people you can employ to work on it, and still be functioning in 5 years time. The same arguments apply to hardware too -- much easier to convince Android developers to fix their app if there is a bug on the Galaxy Note (for example), than some obscure handset.
- hippich 12y ago
  be careful with it tho. it also depends on the reasons why project is popular. for example, wordpress is popular is because it is so easy to setup and bring to life for person with little to no technical knowledge. but other side of the medal is that code you see contributed by community often will be of very low quality. Same applies to javascript frameworks, and I bet, to hardware too (although I don't have example for hardware of top of my head)
woah 12y ago
Something that is sometimes seen as a "marketing" type thing is documentation. However, good documentation is a clear indicator of a better project, if only because it makes it qualitatively easier to implement. I'm going to choose the project with the clear, attractive, well written guide and api docs over the project where I have to dig through pull requests to find method names. Worse are the projects that actually expect you to look at the tests as the only form of docs. This indicates that the author does not care about whether you have an easy time using the project, and that it was only written for their own amusement. A well done project website shows that the author wants you to have an easy time working with the code, and is "putting out a welcome mat". Compare mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury with vue: http://vuejs.org/ http://vuejs.org/. mercury is likely the "better" framework, with it's reactive approach, but in vue, there is attention to detail and documentation through and through. So vue is inevitably what I recommend to backend developers or others who just want to get something done.
- jnbiche 12y ago
  I don't use Vue.js (I use React), but I agree that the project is extremely well-documented and beginner-friendly. The project also has 3400 stars on Github, so the lead dev is gaining some significant popularity. Furthermore, a number of for-profit businesses are almost certainly using the framework in production, as a key part of their websites (Optimizely is cited on their web site as using it in production, but I'm positive there are others). And yet, for all his efforts, the developer is given $5.00 a month on his prominently displayed Gratispay account: https://gratipay.com/yyx990803/ https://gratipay.com/yyx990803/ $5.00. A single Starbucks cappuccino. A month. When I see things like this, it makes me despair of ever making a decent living doing open source software (I have some semi-popular projects, but nowhere near the level of Vue.js). In the end, it also makes me wonder if open source development isn't devaluing the software profession in terms of compensation and prestige. If seems like if people don't pay for something, they just don't respect it, regardless of how useful, well-documented, and well-designed it may be. I love open source, but every time I see a super popular project with only a few dollars of total donations, or hear the lead dev of a open source project used by massive companies around the world tell me he's barely making a living, part of me dies inside.
  - sholanozie 12y ago
    This isn't unique to software; the lowered barriers to creation has meant that the value of almost everything has dropped to the point of worthlessness. While you may not be able to make a living from your open source software through donations, you can certainly make a living by providing support to businesses or assisting with integrations/migrations. We are seeing a shift towards a service-oriented industry, rather than a product-oriented industry, and I expect the rate at which this transformation is taking place to drastically increase in the near future.
thwarted 12y ago
if you're running a business there are good reasons to choose tools that are reasonably well known and widely used, regardless of whether they're the absolute best available on the market. The biggest reason being that it's a lot easier to find developers who know or are interested in learning a popular tool than an obscure one. Recently, I've been questioning the exact value of using popular tools because it's easier to find developers (vs other reasons). So much of what a business is building and providing is bespoke. Even if you use a popular framework that makes your job posting buzzword compliant, that can end up being a relatively small portion of the knowledge required to actually be effective writing software for your business's industry. This goes doubly for organically created internal business processes, which are, nearly by definition, bespoke and won't be found in exact form anywhere else. Now, if you've got good, strong project managers who know your business's industry (rare, IME), then maybe the primary knowledge/experience the programmers need is only on specific frameworks. Obviously there's a lot of wiggle room here. Both early stage and established companies and code bases could make use of people who are either wide breadth or deep depth, there is no one guiding principle. Are you really going to turn down the candidate who knows 15 languages and frameworks but doesn't know the one you use? Or is this just your bias because you don't feel you'd be able to effectively interview them because you don't know as much as they do?
- cauterized 12y ago
  It's not just about screening people for already knowing the tools. It's also about finding people interested in learning or using them. For instance, I'd imagine it's really difficult to recruit developers willing to work on software built in Cold Fusion if it's not already their preferred language. The same goes for anything new and sufficiently obscure. That limits your hiring pool significantly. And for the newer ones means you're unlikely to be able to find anyone with a deep understanding of your language or framework (or DBMS)'s internals.

CJefferson 12y ago

I agree entirely. Long ago, I got some amazing advice, which has helped me to this day. "When you have n choices, and you aren't positive which to choose, choose the more popular one". I used to think this advice was about "the more popular is better". Now I don't think that's true. But the more popular is (in the case of software for example) more likely to be tested on more OSes, or have questions with good answers on stackexchange, have people you can employ to work on it, and still be functioning in 5 years time. The same arguments apply to hardware too -- much easier to convince Android developers to fix their app if there is a bug on the Galaxy Note (for example), than some obscure handset.

hippich 12y ago
be careful with it tho. it also depends on the reasons why project is popular. for example, wordpress is popular is because it is so easy to setup and bring to life for person with little to no technical knowledge. but other side of the medal is that code you see contributed by community often will be of very low quality. Same applies to javascript frameworks, and I bet, to hardware too (although I don't have example for hardware of top of my head)

woah 12y ago

Something that is sometimes seen as a "marketing" type thing is documentation. However, good documentation is a clear indicator of a better project, if only because it makes it qualitatively easier to implement. I'm going to choose the project with the clear, attractive, well written guide and api docs over the project where I have to dig through pull requests to find method names. Worse are the projects that actually expect you to look at the tests as the only form of docs. This indicates that the author does not care about whether you have an easy time using the project, and that it was only written for their own amusement. A well done project website shows that the author wants you to have an easy time working with the code, and is "putting out a welcome mat". Compare mercury: https://github.com/Raynos/mercury https://github.com/Raynos/mercury with vue: http://vuejs.org/ http://vuejs.org/. mercury is likely the "better" framework, with it's reactive approach, but in vue, there is attention to detail and documentation through and through. So vue is inevitably what I recommend to backend developers or others who just want to get something done.

jnbiche 12y ago
I don't use Vue.js (I use React), but I agree that the project is extremely well-documented and beginner-friendly. The project also has 3400 stars on Github, so the lead dev is gaining some significant popularity. Furthermore, a number of for-profit businesses are almost certainly using the framework in production, as a key part of their websites (Optimizely is cited on their web site as using it in production, but I'm positive there are others). And yet, for all his efforts, the developer is given $5.00 a month on his prominently displayed Gratispay account: https://gratipay.com/yyx990803/ https://gratipay.com/yyx990803/ $5.00. A single Starbucks cappuccino. A month. When I see things like this, it makes me despair of ever making a decent living doing open source software (I have some semi-popular projects, but nowhere near the level of Vue.js). In the end, it also makes me wonder if open source development isn't devaluing the software profession in terms of compensation and prestige. If seems like if people don't pay for something, they just don't respect it, regardless of how useful, well-documented, and well-designed it may be. I love open source, but every time I see a super popular project with only a few dollars of total donations, or hear the lead dev of a open source project used by massive companies around the world tell me he's barely making a living, part of me dies inside.
- sholanozie 12y ago
  This isn't unique to software; the lowered barriers to creation has meant that the value of almost everything has dropped to the point of worthlessness. While you may not be able to make a living from your open source software through donations, you can certainly make a living by providing support to businesses or assisting with integrations/migrations. We are seeing a shift towards a service-oriented industry, rather than a product-oriented industry, and I expect the rate at which this transformation is taking place to drastically increase in the near future.

thwarted 12y ago

if you're running a business there are good reasons to choose tools that are reasonably well known and widely used, regardless of whether they're the absolute best available on the market. The biggest reason being that it's a lot easier to find developers who know or are interested in learning a popular tool than an obscure one. Recently, I've been questioning the exact value of using popular tools because it's easier to find developers (vs other reasons). So much of what a business is building and providing is bespoke. Even if you use a popular framework that makes your job posting buzzword compliant, that can end up being a relatively small portion of the knowledge required to actually be effective writing software for your business's industry. This goes doubly for organically created internal business processes, which are, nearly by definition, bespoke and won't be found in exact form anywhere else. Now, if you've got good, strong project managers who know your business's industry (rare, IME), then maybe the primary knowledge/experience the programmers need is only on specific frameworks. Obviously there's a lot of wiggle room here. Both early stage and established companies and code bases could make use of people who are either wide breadth or deep depth, there is no one guiding principle. Are you really going to turn down the candidate who knows 15 languages and frameworks but doesn't know the one you use? Or is this just your bias because you don't feel you'd be able to effectively interview them because you don't know as much as they do?

cauterized 12y ago
It's not just about screening people for already knowing the tools. It's also about finding people interested in learning or using them. For instance, I'd imagine it's really difficult to recruit developers willing to work on software built in Cold Fusion if it's not already their preferred language. The same goes for anything new and sufficiently obscure. That limits your hiring pool significantly. And for the newer ones means you're unlikely to be able to find anyone with a deep understanding of your language or framework (or DBMS)'s internals.