Wow, this is quite a thread, and quite a blowup, obviously about much more 
than pronouns.  There are a lot of different issues here, although 
fundamentally there are two parts that are the most important: one that's 
easy to define, and one that's much much harder.

1. Who legally owns the Node.js trademarks?  That's easy, or at least 
reasonably easy to determine.  The wordmark is owned by Joyent, Inc.:

  http://www.trademarkia.com/nodejs-85262623.html

2. What does the community want to do, and how efficient are the committers 
(who write the code and publish websites about the technology) at 
organizing themselves around a shared goal?  That's hard, as any question 
dealing with a lot of people working together usually is.

Another key issue that I often find engineers tend to under-estimate is the 
appearance of their brand and their work to the larger world.  I.e. who in 
this community is going to be most effective at taking their message not 
just to the existing core contributors to the Node.js code, but more to the 
outside world of new users and corporations who might want to use it - and 
therefore contribute new things to it.  This focus on the larger impact 
outside of just the core community is often (for better or worse!) 
something that for-profit corporations tend to be better at than passionate 
engineers working on it just for the community or for a smaller company.

In any case, a number of people were talking about the ASF, and I wanted to 
add a few useful links about how Apache projects work for those that are 
interested.  The most important thing to understand is that there is no one 
typical Apache project: every project has it's own community with it's own 
way of doing things.  Generalizing behavior over 140+ active project 
communities at Apache is not a good way to understand us.  8-)

By definition, the ASF has a fairly small set of hard rules that must be 
followed for Apache projects.  These include branding yourself as "Apache 
Foo", using ASF infrastructure to store the master repo, some basic [VOTE] 
rules on adding committers and making releases, using the Apache license, 
and PMCs managing projects independently.  Beyond that, the ASF has a 
variety of sets of best practices for managing communities, deciding 
consensus, and the like, but those are all just best practices, and healthy 
communities are allowed to chose their own ways of doing things within them.

But the thing I find most interesting for this conversation is the concept 
that Apache projects must be managed independently.  These behaviors are 
*required* for any Apache project:

  http://community.apache.org/projectIndependence.html

That's the fundamental difference between Node.js at it's current home at 
Joyent, and the potential idea of an "Apache Node.js" project.  Currently, 
Joyent owns the trademark, and over the long term, it's likely their 
overriding goal will be corporate profits.  Fundamentally, the ASF is a 
public charity, and it's long term goal is providing software for the 
public good.

I'm not saying that Apache is the right home for Node.js - we'd certainly 
be thrilled if people were interested in joining the ASF! - that's truly up 
to the community of people doing the actual work to decide.  But I did want 
to explain a bit about how Apache projects work in case people were 
considering that idea.

Thanks for reading,
- Shane



-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to