6 ms·

Popularity-driven development

83 points by mparramon 12y ago

comboy 12y ago
Especially in ruby world, it's amazing how big impact marketing has on open source projects. It's nothing new that when you prepare a nice webpage with some pictures and logo your project is more likely to gain some traction. But mentioned element of social media and virality makes sometimes seemingly random projects to become popular. It would seem that when releasing an open source project, your webdesign and marketing skills are way more important than your programming skills. It gets fixed a bit later because when project becomes popular some good programmers join in and get rid of some silly bugs and so on. But the original design and assumptions stay. API often stays. And since I consider programming nowadays being a lot of like building from lego blocks, API has a huge influence on programmers productivity.
- qznc 12y ago
  So instead of discussing "Worse is better" vs "Worse is worse", we should talk about "Presentation is better".
  - semperfaux 12y ago
    "Better presentation is more effective at attracting attention" would, I think, be the only reasonable conclusion here (and then only because it seems axiomatic). In that context, it would be interest to talk to someone like kalzumeus about testing developer response to various methods of presentation for open source projects, not only to see what works in that regard, but to see whether contributors and adopters respond to the same sort of cues you'd expect to encourage consumer behavior.
- kyllo 12y ago
  Marketing shows that a project has some money behind it, which is a good sign it's going to be supported for a while, which allays the biggest fear most people and organizations have when selecting an open source tool: "is it abandonware?"
  - mattgreenrocks 12y ago
    I guess actually evaluating the project itself is completely out of the question? Or you could, you know, adopt it and continue it? The idea that the technical excellence of open source is secondary to it's marketing/influence is toxic at it's core, and reflects yet another way that developer culture has been infected by Business. Developers focus more on amassing influence than raw skills. We're told to work on 'important' open source projects (remember when everyone fell over themselves to say they contributed to Rails?) and to jump on bandwagons. We're exhorted to take Github stars and activity streaks seriously (lol). And we're told that we can never do enough marketing for our open source projects, that we should buy domain names, blog about it, write more documentation, do bugfixes in a speedy fashion, speak, and maintain social media handles. This will only get worse over time, because we're all convinced we have to amass influence. We're literally working ourselves to death for a few values stored in a database.
- sholanozie 12y ago
  This is the case in every industry right now, and has been since the beginning of time. Marketing is the ability to influence people. It seems obvious to say this, but people who can influence people are usually the people with the most successful products (see: politicians, Apple, pg, etc.).
oinksoft 12y ago
> _I was there_ ... In 2007, at the beginning of my journey > I started this blog. I remember my first JavaScript > tutorial which gained a lot of readers, even though I > wasn’t the expert in the field ... So when I recommended > jQuery, some people followed me in this opinion and tried > it. This post was a fun read simply because my own career path is not unlike the author's. I spent this time in comp.lang.javascript (;^)) and ##javscript, where I learned pretty quickly that I was decidedly not hot shit and that even frontend JavaScript development already had a significant history. Today I wouldn't entertain the idea that I was present at the start of some turning point, it was just the start of another career. Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts). Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts. Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...
- qznc 12y ago
  Impostor syndrome?
- pcthrowaway 12y ago
  jQuery is beautiful and meticulously engineered (and also modularized) to a level far beyond other DOM manipulation/cross-browser compatibility/animation/promise/wart abstraction/whatever else libraries. It may not be the best at everything, and it's certainly not minimalist (though its components are now designed to be independent and customizable) but it is the meeting of many good practices and informed design across its many capabilities. It's the everything-and-the-kitchen-sink philosophy (with a focus on performance). > Given that all of the other libraries implemented a comparable selector engine This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`). If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'
thetmkay 12y ago
This is a slight diversion, but if you're interested in the topic of popularity-driven ethics (diction?) you may be interested in the novel by Cory Doctorow called "Down and Out in the Magic Kingdom" http://craphound.com/down/ http://craphound.com/down/ I only read it recently, and in addition to recommending it as an enjoyable sci-fi read, one of the themes is the use of system called 'Whuffie', which is a reputation-based metric that permeates all of society, including politics and economics.
jkot 12y ago
If you make living out of your OS project, popularity and huge number of users might not be necessary good thing. It all comes down to conversion rate, community maintenance cost etc...
cauterized 12y ago
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.
drapper 12y ago
Popularity might not be the best indicator of quality, but it's a pretty good indicator of longevity of the project - and this is, I think, more important, in the long term at least. All the technical superiority of an unpopular library will amount to nothing if couple of months down the road the author will not be interested in fixing some obscure, but important bug, nor there will be anyone to take on the maintenance from him/her.
- awinder 12y ago
  Importantly, like you said, it's also the measure of some level of quality. It's incredibly, incredibly rare that a tech project becomes popular without any level of quality. A lot of people could do much worse than that combination (some quality + longevity)
  - dragonwriter 12y ago
    Nothing exists without some (possibly very low) level of quality, but by any measure of quality other than popularity itself, popular things may fall anywhere in the quality spectrum.
- mikegerwitz 12y ago
  > Popularity might not be the best indicator of quality, but it's a pretty good indicator of longevity of the project Certain projects have either a niche audience, are less known, less easily groked by users, etc.
lhorie 12y ago
Here's my experience, being an author of an "underdog" js framework. My project (Mithril.js) has ~2600 stars on github, a relatively lively mailing list, and it's on the front page of todomvc, so it's definitely more popular than many "competitor" projects, although not nearly as popular as Angular or Ember. My general impression of the landscape is that affiliation w/ a famous brand helps a lot in driving adoption. Being a guy in the outskirts of Toronto, working on the project on my spare time (with two small kids), it's pretty hard to compete w/ teams that get paid full time and get opportunities to talk at big conferences in San Francisco. I'm skeptical that this kind of gap can be made narrower with hard/good technical work alone. This reality weaves deep even into the design philosophy of Mithril: one reason the project is small is that I don't have the resources to tech-support a huge complex one. Lack of time is obviously not a selling point, so the design of the framework itself needs to account for it - I put a lot of thought into reducing learning curve and framework complexity because that is something that both reduces my workload as a support person, and is itself a selling point (especially considering all the recent Angular criticisms). I think the only reasons my project enjoys any popularity at all is the efforts I put into non-coding tasks: writing docs (took me like 2 months of writing docs nearly exclusively to get to what I consider a decent level of documentation, even despite having a tiny API), writing articles, talking to the community, getting on twitter, adding shameless plugs on HN :) etc. In a way, this is similar to being a startup founder: there's a lot of peripheral stuff to do. It's not uncommon to be spending more time on non-coding aspects of the project than actually coding.
- thunderbong 12y ago
  http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/
- pelonpelon 12y ago
  Why I'm coding with Mithril... I have experience creating a very complex React app to organize a conference. It included registration, authentication, personalized schedules and calendars, news articles, up-to-the-minute updates, a store, physical pass(ID) verification, and a few dashboards for use by clients of my client. Honestly, it was a lovely experience. Once in the React rhythm, the coding became an exercise in pattern application. This was before Flux came along. Presently, 58% of users of my current client's site arrive via mobile and minified React tops 145kb, which takes a lot of time to deliver and unpack. I serve 1000 new users per week who can't rely on finding React in their browser cache. This is too much overhead. I am a little obsessed with under-one-second loading and 3 second attention spans. Non-minified React is 642kb and that's too much code for me to grok if I want to understand what my application is doing. I did some work converting Bootstrap to React and ramping up took too much of my time. Then I found Mithril. It's faster than anything. It's tiny. It does only what it needs to do, no bloat. And it does most of the good stuff that React does. It's also FRP friendly, another current obsession of mine. It's in the early stages, but it is so small and focused that it can be used anywhere. TODAY. Consider it code you would have written on your own if you'd had the time (and were a VERY talented js coder). mithril.js is small enough to understand in detail. It's so well designed that even an intermediate dev like me can grasp it. Beyond the basic documentation is a blog and API docs written as precisely and as focused as the code. The API is so small you can master it in an hour or two. It's a testament to its quality that the earliest blog entries are applicable today. I recommend reading them from oldest to newest. They read more like a tutorial than a blog. Post a question to the Google Group and Leo will likely refer you back to a blog post because he's already covered your question. Another sign that Mithril is of great quality: most public discussion about Mithril revolves around the philosophy and logic of app design, not code errors. When errors are discovered, Leo patches them within hours if not minutes. Leo got so much right. Most things right. More than any other framework I know.

83 points by mparramon 12y ago

Especially in ruby world, it's amazing how big impact marketing has on open source projects. It's nothing new that when you prepare a nice webpage with some pictures and logo your project is more likely to gain some traction. But mentioned element of social media and virality makes sometimes seemingly random projects to become popular. It would seem that when releasing an open source project, your webdesign and marketing skills are way more important than your programming skills. It gets fixed a bit later because when project becomes popular some good programmers join in and get rid of some silly bugs and so on. But the original design and assumptions stay. API often stays. And since I consider programming nowadays being a lot of like building from lego blocks, API has a huge influence on programmers productivity.

qznc 12y ago
So instead of discussing "Worse is better" vs "Worse is worse", we should talk about "Presentation is better".
- semperfaux 12y ago
  "Better presentation is more effective at attracting attention" would, I think, be the only reasonable conclusion here (and then only because it seems axiomatic). In that context, it would be interest to talk to someone like kalzumeus about testing developer response to various methods of presentation for open source projects, not only to see what works in that regard, but to see whether contributors and adopters respond to the same sort of cues you'd expect to encourage consumer behavior.
kyllo 12y ago
Marketing shows that a project has some money behind it, which is a good sign it's going to be supported for a while, which allays the biggest fear most people and organizations have when selecting an open source tool: "is it abandonware?"
- mattgreenrocks 12y ago
  I guess actually evaluating the project itself is completely out of the question? Or you could, you know, adopt it and continue it? The idea that the technical excellence of open source is secondary to it's marketing/influence is toxic at it's core, and reflects yet another way that developer culture has been infected by Business. Developers focus more on amassing influence than raw skills. We're told to work on 'important' open source projects (remember when everyone fell over themselves to say they contributed to Rails?) and to jump on bandwagons. We're exhorted to take Github stars and activity streaks seriously (lol). And we're told that we can never do enough marketing for our open source projects, that we should buy domain names, blog about it, write more documentation, do bugfixes in a speedy fashion, speak, and maintain social media handles. This will only get worse over time, because we're all convinced we have to amass influence. We're literally working ourselves to death for a few values stored in a database.
sholanozie 12y ago
This is the case in every industry right now, and has been since the beginning of time. Marketing is the ability to influence people. It seems obvious to say this, but people who can influence people are usually the people with the most successful products (see: politicians, Apple, pg, etc.).

oinksoft 12y ago

> _I was there_ ... In 2007, at the beginning of my journey > I started this blog. I remember my first JavaScript > tutorial which gained a lot of readers, even though I > wasn’t the expert in the field ... So when I recommended > jQuery, some people followed me in this opinion and tried > it. This post was a fun read simply because my own career path is not unlike the author's. I spent this time in comp.lang.javascript (;^)) and ##javscript, where I learned pretty quickly that I was decidedly not hot shit and that even frontend JavaScript development already had a significant history. Today I wouldn't entertain the idea that I was present at the start of some turning point, it was just the start of another career. Being a neophyte coming from the land of HTML, CSS, and A List Apart, I took to jQuery like a fish to water, but more experienced folks correctly slapped my hand when I championed it (like David Mark, the Voldemort of c.l.j.). I wasn't quite sure why it was so reviled in these circles, but given that I had arrived at these communities to learn and not teach, I went with it and just listened (and didn't write blog posts). Over time I saw jQuery for the abomination it is. A very usable, imprecise API that has "fluent interface" and a selector engine as its chief selling points, where a single prototype is the God object to end all God objects. Given that all of the other libraries implemented a comparable selector engine, I never felt deprived when working with Prototype, or MooTools, or Ext.js, or ultimately Google Closure. I could see that designs written with these other libraries were far more comprehensible and cohesive than what was coming out of the jQuery world, but to oppose the jQuery tidal wave was a fool's errand, so I just kept writing lots of software for my employers, and didn't write blog posts. Maybe some day the history of how jQuery "made it" will be written. It seems like a shining example of "Worse is Better." Recommendations like the one from the author were just the blind leading the blind. Now we're stuck with it. Maybe more of us who felt this way should have written blog posts, but as the author hints, that's the paradox! You can spend so much time writing software, or spreading ideas, but seldom is there time to do both prolifically. I still don't feel qualified to write blog posts like this one...

qznc 12y ago
Impostor syndrome?
pcthrowaway 12y ago
jQuery is beautiful and meticulously engineered (and also modularized) to a level far beyond other DOM manipulation/cross-browser compatibility/animation/promise/wart abstraction/whatever else libraries. It may not be the best at everything, and it's certainly not minimalist (though its components are now designed to be independent and customizable) but it is the meeting of many good practices and informed design across its many capabilities. It's the everything-and-the-kitchen-sink philosophy (with a focus on performance). > Given that all of the other libraries implemented a comparable selector engine This is not true; other libraries implement their own selector engines which, while (sometimes) smaller in size, are also less feature-rich. Sizzle (jQuery's independently developed selector engine) provides many additional selectors not currently available in the browser (such as nested pseudo-selectors: `:not(:has(div:first-child))`). If none of this appeals to you, you are welcome to use a different library. There are lots of other strong options. But just because jQuery doesn't fit your needs doesn't make it 'an abomination'

thetmkay 12y ago

This is a slight diversion, but if you're interested in the topic of popularity-driven ethics (diction?) you may be interested in the novel by Cory Doctorow called "Down and Out in the Magic Kingdom" http://craphound.com/down/ http://craphound.com/down/ I only read it recently, and in addition to recommending it as an enjoyable sci-fi read, one of the themes is the use of system called 'Whuffie', which is a reputation-based metric that permeates all of society, including politics and economics.

jkot 12y ago

If you make living out of your OS project, popularity and huge number of users might not be necessary good thing. It all comes down to conversion rate, community maintenance cost etc...

cauterized 12y ago

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.

drapper 12y ago

Popularity might not be the best indicator of quality, but it's a pretty good indicator of longevity of the project - and this is, I think, more important, in the long term at least. All the technical superiority of an unpopular library will amount to nothing if couple of months down the road the author will not be interested in fixing some obscure, but important bug, nor there will be anyone to take on the maintenance from him/her.

awinder 12y ago
Importantly, like you said, it's also the measure of some level of quality. It's incredibly, incredibly rare that a tech project becomes popular without any level of quality. A lot of people could do much worse than that combination (some quality + longevity)
- dragonwriter 12y ago
  Nothing exists without some (possibly very low) level of quality, but by any measure of quality other than popularity itself, popular things may fall anywhere in the quality spectrum.
mikegerwitz 12y ago
> Popularity might not be the best indicator of quality, but it's a pretty good indicator of longevity of the project Certain projects have either a niche audience, are less known, less easily groked by users, etc.

lhorie 12y ago

Here's my experience, being an author of an "underdog" js framework. My project (Mithril.js) has ~2600 stars on github, a relatively lively mailing list, and it's on the front page of todomvc, so it's definitely more popular than many "competitor" projects, although not nearly as popular as Angular or Ember. My general impression of the landscape is that affiliation w/ a famous brand helps a lot in driving adoption. Being a guy in the outskirts of Toronto, working on the project on my spare time (with two small kids), it's pretty hard to compete w/ teams that get paid full time and get opportunities to talk at big conferences in San Francisco. I'm skeptical that this kind of gap can be made narrower with hard/good technical work alone. This reality weaves deep even into the design philosophy of Mithril: one reason the project is small is that I don't have the resources to tech-support a huge complex one. Lack of time is obviously not a selling point, so the design of the framework itself needs to account for it - I put a lot of thought into reducing learning curve and framework complexity because that is something that both reduces my workload as a support person, and is itself a selling point (especially considering all the recent Angular criticisms). I think the only reasons my project enjoys any popularity at all is the efforts I put into non-coding tasks: writing docs (took me like 2 months of writing docs nearly exclusively to get to what I consider a decent level of documentation, even despite having a tiny API), writing articles, talking to the community, getting on twitter, adding shameless plugs on HN :) etc. In a way, this is similar to being a startup founder: there's a lot of peripheral stuff to do. It's not uncommon to be spending more time on non-coding aspects of the project than actually coding.

thunderbong 12y ago
http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/
pelonpelon 12y ago
Why I'm coding with Mithril... I have experience creating a very complex React app to organize a conference. It included registration, authentication, personalized schedules and calendars, news articles, up-to-the-minute updates, a store, physical pass(ID) verification, and a few dashboards for use by clients of my client. Honestly, it was a lovely experience. Once in the React rhythm, the coding became an exercise in pattern application. This was before Flux came along. Presently, 58% of users of my current client's site arrive via mobile and minified React tops 145kb, which takes a lot of time to deliver and unpack. I serve 1000 new users per week who can't rely on finding React in their browser cache. This is too much overhead. I am a little obsessed with under-one-second loading and 3 second attention spans. Non-minified React is 642kb and that's too much code for me to grok if I want to understand what my application is doing. I did some work converting Bootstrap to React and ramping up took too much of my time. Then I found Mithril. It's faster than anything. It's tiny. It does only what it needs to do, no bloat. And it does most of the good stuff that React does. It's also FRP friendly, another current obsession of mine. It's in the early stages, but it is so small and focused that it can be used anywhere. TODAY. Consider it code you would have written on your own if you'd had the time (and were a VERY talented js coder). mithril.js is small enough to understand in detail. It's so well designed that even an intermediate dev like me can grasp it. Beyond the basic documentation is a blog and API docs written as precisely and as focused as the code. The API is so small you can master it in an hour or two. It's a testament to its quality that the earliest blog entries are applicable today. I recommend reading them from oldest to newest. They read more like a tutorial than a blog. Post a question to the Google Group and Leo will likely refer you back to a blog post because he's already covered your question. Another sign that Mithril is of great quality: most public discussion about Mithril revolves around the philosophy and logic of app design, not code errors. When errors are discovered, Leo patches them within hours if not minutes. Leo got so much right. Most things right. More than any other framework I know.