It's what happens when you sell tickets to companies, for a price that is too high, and incentivize people to sell to their friends for some bounty you offer.

This isn't necessarily wrong, but trying to mask it as a "good thing" is naive at best.

ps. From an actual email sent to me from someone I have no idea who it is:

As an active participant in these technologies, you may be interested in joining our Conference Affiliate Program for Fluent. If you'd like to become an affiliate, you can link to the event through your blog/website and earn affiliate fees of $250 for every eligible referral. It's simple and takes minutes to sign up, so take a look and let me know if have any questions. To participate, sign up directly on this online form and we'll send you everything you need to get started within a couple of days: http://fluentconf.com/fluent2012/public/sv/q/398

The latter part certainly wasn't true. I can't share details but having seen the data, the number of attendees who came in via that method was pointlessly low from my POV. Perhaps it works well on other events, but I thought offering a plan like this on a first time conference was a bit silly.. who's going to refer someone to an event they know nothing about? ;-)

Were the tickets relatively high priced and primarily sold to company-affiliated developers? I think that's fair to say. That's O'Reilly's approach for its conferences. I can't change that, but I think it's a market worth serving in any case, especially as other audience types are well served by other events in the JS world.

Naïvely or not, I think having a diverse audience of both beginners and experts is a good thing, especially when those beginners were saying they were leaving with so many ideas and ambitions to learn about things they'd seen. Not every conference is aiming to bring beginners into the fold, but O'Reilly seems to promote this approach (consider they have a full day of workshops, mostly introductions to new technologies, so targeting people ready to learn is intentional from their POV, I think).

Disclaimer: I was a program chair responsible for getting the program right. Everything else is managed and controlled by full time conference organizers at O'Reilly, so most of the above is just my opinion of other people's hard work.

So unlimited permutations of [a-z]?

Sure that makes sense....

You can check the code for the app at - https://github.com/indutny/home.

If you feel like giving node a try this page will get you a nodejitsu invite: - http://gimmesomebeta.jit.su

* Got all the core team members talking about where nodejs is going * Does live events with 150 people nerding out and drinking beer.

It's an obvious miss.

http://nodejs.org/docs/lates/api/http.html#http.ServerRespon...

This is perhaps the most depressing response I've received to my article.

As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community.

Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects?

Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader.

I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy.

I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.

The Apache Foundation is what you make of it. It will not change just because you post to your blog, but it will change if you engage the committer and membership population, build a consensus around your ideas and volunteer to do the actual work to make the changes happen.

No one will force you to do such work and if you don't want to do it, then you're not obligated to do so. No one will be upset if you, I or anyone else leaves the Foundation. It's cool. We're all here at-will, volunteering effort and code.

Apache cannot be everything to everyone, despite how much it is pulled to be so. Right now it fills a particular important role in the open source and larger software ecosystems. It's in that position due to both historical precedent as well as intentional decisions by the membership body.

But trust me, no one in Apache is ever, ever completely satisfied with the Foundation. That's to be expected -- the organization is driven by the compromises of a large group of people with different ideas and expectations. To balance between the chaos of constant change and the death of no change, the organization has grown guidelines and rules from the collected wisdom of its membership. This gives us at least some framework by which to evolve.

As for hosting code, there have been proposals at time for Apache to push the code hosting to some other organization. Once it was SourceForge, then Google Code, now Github. Of course, it's a tricky situation as the Foundation has particular requirements and wants to know its code will be around for decades. Moreover, infra team is constantly understaffed and thus are a very, very conservative bunch. We've seen way too many people jump in with a great idea and then leave maintenance to someone else. They're stubborn for a reason.

And perhaps Apache and Github are incompatible. So what? Github is a tool. It's incompatible with lots and lots of organizations and ways of doing things. The FSF has its rules and culture. Same with the Linux kernel, distros and desktops like KDE and Gnome. Android is different too. Not all of those mesh with Github and that's fine.

This is true only from a CYA standpoint. As Mikeal said in the article, it's possible to do a lot of work and build up a strong case for a change that's important to project maintainers, yet still have Apache come up with excuses for why it can't happen. This is what happened with git -- twice.

He is saying that ASF would benefit from the kind of community development that git promotes as exemplified by GitHub and linux.

More importantly, Git by itself does not promote community development. No source control system does. Some make that style of development easier, but none of them actually directly promote it.

GitHub is not Git. GitHub is the Git version of SourceForge. Nearly all the community development features(bug tracking, forums, etc.) on both sites are built beside the source control system, and aren't really integrated directly to either Git or SVN.

I don't understand why this response is "depressing" and characterizing the reply as "about git" is, frankly, not representative of the post I just read.

Sometimes it just makes more sense to put your own ideas on pause for a bit and help others with theirs.