I think both have valid points, but in such a way that Marijn is right.
I did start cool open source projects without crowd-funding. It happened at
certain points in my life when I didn't really need extra-money (or when I
had sufficient free time — essentially the same thing). It is possible.
Today? I'm not sure I could start anything substantial today without
funding. My life is not the same as it was 3 years ago. Things change, and
somehow paying the bills gradually becomes harder each day than it was the
day before—I don't know why life has to suck this way, but so it happens.
There's quite a narrow frame in everyone's life when one can start major
free projects without any income — and I'm probably approaching the end of
it. Kudos to Marijn for he manages to do so well, and still provide free
tools of outstanding quality! (and in case you didn't notice, the demo is
quite impressive — the thing is alive, not vaporware).
On the Antirez side now, it's true that a project without a community is as
good as dead (he also mentions evolution and bugfixes, but a community is a
prerequisite for that). I certainly have projects that could benefit
enormously from having a community — but it just didn't happen, for some
reason. (OK, I know why: Emacs and Lisp are Just Not Popular).
Tern is not likely to suffer from lacking a community, because it happens
that JS is the most popular language on the planet and Tern solves a Hard
Problem. You could think of Tern as the smarter big brother of JSLint.
JSLint employs brute-force to find potential mistakes, while Tern employs
smartness to help you find real semantic errors, or to improve the way you
write code. It's unique. I don't think it'll suffer from lacking
community—au contraire, I hope the community won't be as invasive as to
murder this project by bringing into it tons of "I'd like my code to look
that way" features — but then again, I trust Marijn for being able to trim
down feature requests and leave in only what's meaningful, rather than
particular use cases; and for particular use cases he will totally be able
to make a living by providing custom support and development and this will
eventually raise the quality of the project on the whole.
I did start cool open source projects without crowd-funding. It happened at certain points in my life when I didn't really need extra-money (or when I had sufficient free time — essentially the same thing). It is possible.
Today? I'm not sure I could start anything substantial today without funding. My life is not the same as it was 3 years ago. Things change, and somehow paying the bills gradually becomes harder each day than it was the day before—I don't know why life has to suck this way, but so it happens.
There's quite a narrow frame in everyone's life when one can start major free projects without any income — and I'm probably approaching the end of it. Kudos to Marijn for he manages to do so well, and still provide free tools of outstanding quality! (and in case you didn't notice, the demo is quite impressive — the thing is alive, not vaporware).
On the Antirez side now, it's true that a project without a community is as good as dead (he also mentions evolution and bugfixes, but a community is a prerequisite for that). I certainly have projects that could benefit enormously from having a community — but it just didn't happen, for some reason. (OK, I know why: Emacs and Lisp are Just Not Popular).
Tern is not likely to suffer from lacking a community, because it happens that JS is the most popular language on the planet and Tern solves a Hard Problem. You could think of Tern as the smarter big brother of JSLint. JSLint employs brute-force to find potential mistakes, while Tern employs smartness to help you find real semantic errors, or to improve the way you write code. It's unique. I don't think it'll suffer from lacking community—au contraire, I hope the community won't be as invasive as to murder this project by bringing into it tons of "I'd like my code to look that way" features — but then again, I trust Marijn for being able to trim down feature requests and leave in only what's meaningful, rather than particular use cases; and for particular use cases he will totally be able to make a living by providing custom support and development and this will eventually raise the quality of the project on the whole.