Popularity-driven development
ferrante.pl
ferrante.pl
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.
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.
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.
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.
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.
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.
Certain projects have either a niche audience, are less known, less easily groked by users, etc.
"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.
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 with vue: 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.
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/
$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.
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?
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.
> _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.
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...
> 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'
Furthermore, jQuery offered a pretty nicely-engineered codebase and a very friendly and predictable API at a time when client-side JS was very unpredictable.
I don't use jQuery much anymore, since it's often just as easy to use plain JS. Plus, I'm often compiling so I can use a ES6 compiler to make it even nicer.
But I definitely leaned heavily on jQuery in the days prior to IE8-IE9 and client-side builds.
And even disregarding all my arguments above, I don't think it's fair to call such a carefully-designed and maintained project an "abomination", even if you do disagree with some of its technical decisions.