In this essay, the term “member” specifically means someone who is a Member of the Foundation itself, as elected per the corporate bylaws.

Organization

The ASF is a membership corporation, so Members serve a similar role as shareholders do in publicly traded corporations. Members may propose new candidate members, may cast one vote in new candidate elections, and may cast one vote in board elections.

Members are not empowered to speak officially on behalf of the ASF as a whole, nor do they have any special rights to influence technical direction of any Apache projects that they are not otherwise elected as a committer or PMC member on. While members often volunteer and serve in many capacities both at the Foundation level and within various Apache projects, their only specific organizational rights are to vote in board and member elections.

The Apache Incubator is special: any ASF member may request to be added to the Incubator PMC without a vote. Within the Incubator PMC, members may serve as official mentors or champions to incoming podlings, as well as voting on Incubator policy and releases of podlings undergoing incubation. In this way, members work to mentor podling communities and guide them to the Apache Way and eventual graduation as a top level Apache project.

Legal

Members act as shareholders of the corporation. As such, each member has a single vote on electing directors to the board; similarly members may vote on new nominees to membership. Members are eligible to nominate new candidate members and to nominate individuals to the board.

Organizationally, members do not have specific standing within any Apache projects or Incubator podlings. However most members are active as individuals within multiple Apache projects on their own technical or social merits, and once elected as a member often find more ways to get involved in more Apache projects.

While the board and relevant officers are directly responsible for providing oversight to the many Apache projects, members often work within many Apache projects to help ensure projects run smoothly and follow the Apache Way.

Communication

The central place for member-focused announcements and discussions is the privately archived members@ mailing list. This is used for a wide variety of purposes: both proposing and discussing new technical or policy ideas within the ASF, announcing marriages or births within member’s families or other major social events, and any formal announcements to the membership from the board or corporate officers.

By policy, members have the right to inspect and review the archives of all mailing lists at Apache. This policy is designed to ensure that every member can independently inspect all corporate operations, and the operations of all Apache projects. Thus members may review all private mailing lists (for example) about internal legal affairs, fundraising, security issues, as well as any private@ lists used by our Apache projects’ PMCs.

While members may send messages to any private lists, they do not automatically receive any special merit in terms of influencing the technical direction of Apache projects. Merit in Apache projects is gained within each individual project community, and membership does not convey any other special privileges.

Meetings

The board typically holds an Annual Members Meeting, where a new board of directors is elected, and new member candidates may be voted upon. Meetings are currently held on a private IRC channel, as an alternative to a traditional conference call, where any reports are read and members may ask questions. The meeting has a 48 hour recess for voting, and then reconvenes to announce results and complete the meeting: this allows members who may not be able to personally attend the first portion of the meeting to attend the second half, as well as to conduct voting over email using our own secure voter tool. Members who are unable to attend any of the 2 day meeting period may provide for another member to proxy their attendance and votes.

The board often holds interim Special Members Meetings in between Annual Meetings, primarily to give members a chance to nominate new candidate members and be voted in. Members also use Special and Annual meetings to raise additional questions or issues about Foundation operations – although members usually just raise questions to the board or to any ASF officer at any time over our usual mailing lists. Members and invited guests are welcome at all Members meetings.

Given the distributed and volunteer nature of the ASF, official in-person meetings of the Membership are no longer held. All Foundation or project business is conducted on normal mailing lists – although some of the lists are private. Members do often meet in small groups in person – although this is for social reasons, and often involves a meal or drinks. Many members and committers also traditionally attend the ASF’s annual ApacheCon conference.

Merit

All members have the ability to nominate new individuals as candidates for membership. The amount and types of merit that existing members look for in Apache committers varies, but always includes some significant technical or other contribution to one or more of our projects, as well as a clear interest and understanding of the Apache Way. In most cases, these contributions and traits are displayed over a significant period of time, usually over a year of engagement in one or more Apache projects.

Note that it is not required to be a committer before being considered for membershp, however as a practical matter, in the vast majority of cases any potentially worthy individual has already become a committer on some Apache project. At least two individuals have been elected as members without being committers first, in each case for non-coding contributions in mentoring on the Apache Way or other organizational work.

Many newly elected members are surprised (pleasantly!) to be told they’ve been elected. Typically, being nominated and elected as a new member is something that happens well after the nominee has a clear track record and a positive influence on Apache projects for some time; in hindsight, a frequent comment is “isn’t So-and-So a member already? They do such good work!”. Individuals asking to be made a member (or worse, insisting you should be elected!) is culturally frowned upon. In a perhaps counter-intuitive way, being considered for membership is something that requires real effort acting over a measureable time, but without making it obvious that you’re seeking recognition.

Candidate members are voted on as a simple majority vote (more yes’es than no’s) at Annual or Special member’s meetings. Voting is performed using custom written voting software with secret ballots.

Within the Membership, merit is equal; all members have an equal vote and ability to propose change within the ASF. Membership is a notably helpful factor in being considered for the board or in appointment to officer positions at the ASF, although the most important factor is demonstrated merit within the particular project or the ASF as a whole.

Community

The ability of members to influence the ASF is simultaneously major and immaterial. On one hand, members vote on new candidate members, and more importantly vote on the Board of Directors, which clearly affects strategic policies of the ASF. On the other hand, membership grants individuals no other special merit within any of our projects, and is not an official position within the legal corporation itself.

The perceived importance of membership is likewise a dichotomy. Many members are quite modest about their membership, and a frequently heard comment is that “oh, they really deserve to be recognized more than I did”. For many, being elected a member was not a goal or title that individuals were pursuing; rather, they were naturally doing their own work (at an Apache project), and were then recognized for it.. Many members list their affiliation on their resume (or LinkedIn, etc.); some do not.

Recognition of membership varies widely outside of the ASF: some software companies don’t seem to care what the ASF is or what membership means; a few software companies have strongly encouraged their employees to become committers or members, and gaining one of those roles is a notable prestige bonus within those companies. Likewise, a number members or officers of the ASF are frequently sought out as speakers at open source conferences.

Members share both the community of all other members, as well as often serving as bridges across the various Apache projects they are already involved in. Many members also volunteer extra time to serve as mentors, both within the ASF working with our projects and communities, and outside of it, mentoring others or speaking at conferences.

Technical

The membership as a whole and individually does not provide technical direction for any Aapche projects directly; every PMC is free to manage it’s technical direction independently. PMCs are the governing body for their project, and are expected to manage the project’s technology in the best interest of the whole project community, independent of outside commercial influence.

This is similar to how the board does not set technical direction for projects: this is a key reflection of how the ASF is intentionally structured to provide maximum freedom to it’s projects. The board and the ASF membership are happy to provide a home to any software project communities that are willing to follow the Apache Way. The mission of the ASF is to provide software for the common good: we are happy to help like-minded communities to provide that software; are confident that communities will form around software that is useful; and understand that there are many different ways to effectively and collaboratively build software.

In the case of members, nearly all members do participate in a number of Apache projects – as individuals based on their merit within the specific projects. Simply being elected a member does not confer any additional abilities in terms of other projects. Many members chose to serve as ambassadors of the Apache Way, and usually get involved in more projects as time goes on.

Resources

• Bylaws of the ASF/li>
• List of current ASF Members, list including project affiliations/li>
• Overview of Foundation Governance/li>
• Graph of Membership Growth

Organization

Apache projects are managed by Project Management Committees (PMCs), comprised of committers elected within a specific project community to provide oversight for the project for the ASF and to decide the release strategy for the project. PMC members are expected to act as individuals, making decisions for the best interest of the project when acting on PMC or development lists.

Each project’s PMC is independent. PMCs are free to set community and technical direction for their project, and are directly responsible for overseeing releases and the healthy development of their communities. PMCs are responsible for ensuring their project follows certain core requirements set by the board or other corporate officers of the ASF, like following Legal, Branding, and Infrastructure related requirements, along with ensuring their community operates within the basic outline of the Apache Way.

PMC members nominate new contributors to the project as committers, and PMC members cast votes on electing new committers to the project. PMC members also have binding votes on any project matters.

Legal

The board creates new PMCs to manage specific named projects by resolution at monthly meetings. New top level projects (TLPs) are created from podlings in the Apache Incubator after a successful graduation vote from Incubation. The board appoints a Vice President – an officer of the corporation – to serve as the chair of the PMC itself when creating the PMC.

PMC Chairs – who are VPs – serve as normal PMC members, with one vote on project matters just like other PMC members. The primary duty of a PMC chair is providing quarterly reports to the board about the health and status of their project. PMC chairs are expected to subscribe to the board@ mailing list, and be aware of any board concerns about the project, and are responsible for working with the PMC as a whole to address any board concerns.

When PMCs elect new potential PMC members or existing members resign, the chair of a project requests an “ACK” from the board. Once one director ACK’s email is sent recognizing the change in the PMC membership, and after a 72 hour wait, the PMC chair may update the official roster of the members of that PMC. The ACK process is designed to ensure that all PMC changes are explicitly acknowledged by the board, and the waiting period ensures that all directors have a chance to object or comment on any improper changes. Changes in PMC chairs are only made by board resolution at monthly meetings, since this involves appointment of an officer of the ASF.

As official committees of the ASF, PMCs provide the legal oversight of project operations and releases, ensuring that software releases are made on behalf of the ASF as an organization, and not as individuals. This helps to ensures that any legal liability for the products of Apache projects is born by the ASF and not by our committers individually. All PMC chairs provide quarterly reports to the board, which ensures that the board has oversight of all the projects of the Foundation.

Communication

PMC members should always be subscribed to their project’s private@ list, and certainly should be subscribed to at least the dev@ list to be aware of the operations of the project.

Virtually all PMC communication should happen on the dev@ list or any other appropriate public mailing list. The private@ list for each PMC should only be used for matters that require confidentiality, such as discussing personnel matters or voting in new committers or PMC members, or security-related issues that have not yet been publicly disclosed. Ensuring that PMC discussions about the future of the project are held on the public dev@ list ensures that all of the community – including non-committers – can follow the discussion and comment on issues. While only PMC members or committers have binding votes on project matters, healthy PMCs certainly work with the larger community of their project.

PMCs are free to use JIRA/Bugzilla, wikis, and other infrastructure-hosted tools that provide for public view and comment, along with the normal project mailing lists. PMCs should make specific requests to the Infrastructure team for services that the project desires.

Meetings

Some PMCs sponsor regular or occasional in person meetings, teleconferences, or IRC chats to brainstorm project ideas, but are expected to bring all information back to public lists for further discussion and to make final decisions. Many PMCs either directly organize, or have contributors or organizations in their technical space organize Meetups, BarCamps, or other in-person events focused on end user education and technical information sharing.

Given the distributed and volunteer nature of our projects, in-person meetings of PMCs are quite rare. All project business is conducted on normal public mailing lists.

Merit

PMCs are free to set the bar for merit within their projects, as long as decision making is done in a collaborative fashion as in the Apache Way. Healthy PMCs will regularly review contributions from non-committers – both specific code patches, bugs reported or commented on, or just helpful interaction on their project lists – to evaluate contributors as potential committers. Ensuring that PMC members are helping to mentor helpful new contributors to their projects helps to ensure a healthy and growing project community.

PMCs vary significantly in the level of commitment and work expected to be considered for a committership. Some PMCs vote in new PMC members typically from their existing committers (i.e. the progression is contributor -> vote -> committer -> vote -> PMC), while other PMCs always elect new committers into the PMC simultaneously (contributor -> vote -> committer & PMC member). PMCs are solely responsible for managing votes and granting commit privileges for new committers; however new PMC members elected must always be ACK’d by the board before they are officially added to the PMC.

Merit within one PMC is not transferable to other PMCs; each project’s committer list is independently managed by it’s own PMC. PMC members or committers with a long history on one project will often be known by their past activities by other project’s PMC members, but they are expected to build merit on each separate project they wish to become a committer on.

Community

While only PMC members have binding votes on project releases, in general PMC members participate equally with their project committers on the dev@ list. PMC members can help to ensure a healthy and diverse project community by ensuring the project’s mailing lists are welcoming to newcomers and that community standards are promoted on it’s mailing lists.

While there are many projects with overlapping communities – and therefore some shared personal or technical relationships – fundamentally each project is it’s own community in terms of the bulk of project work. While all projects are part of the overall ASF, and as such share certain basic requirements and bits of the Apache Way, all technical direction and most of the community focus is within each project individually.

PMCs are expected to report on the health and diversity of their project’s community to the board. While there are no strict requirements on the makeup of PMC members (in terms of employment or affiliation of the individuals on the PMC), the board does expect PMCs to operate independently of outside commercial influence. PMCs that are unable or unwilling to ensure their actions are on behalf of the whole community – or act in ways targeted to specific commercial interests – will be contacted by the board and required to make corrections.

Technical

The board does not provide technical direction for any of it’s projects or activities; every PMC is free to manage it’s technical direction independently. PMCs are the governing body for their project, and are expected to manage the project’s technology in the best interest of the whole project community, independent of outside commercial influence.

While this may be a surprise to some, it is a key reflection of how the ASF is intentionally structured to provide maximum freedom to it’s projects. The board and the ASF are happy to provide a home to any software project communities that are willing to follow the Apache Way. The mission of the ASF is to provide software for the common good: we are happy to help like-minded communities to provide that software; are confident that communities will form around software that is useful; and understand that there are many different ways to effectively and collaboratively build software.

Advice

One of the most important pieces of advice I’d personally give to PMC members is to feel a sense of leadership and responsibility for their projects as independent projects. Apache relies on it’s PMC members to ensure that their projects are managed in an open and fair manner, and that their projects act to serve the public interest by providing free software under the Apache License. In many ways, PMC membership is a duty to the project as a whole, and a call to set aside outside influence to act for the best interests of the project’s active community itself.

Resources

• Project Management Committee Guide – how-to of PMC duties
• PMC Branding Responsibilities – ensuring their projects follow Apache Branding Requirements
• Podling Project Management Committee Guide – expectations for Incbator podlings’ governance
• Brief overview of what a PMC is from the How It Works
• Apache Projects are Independent

Organization

The board consists of 9 directors, each serving as an individual. After each annual board election, the board chooses a Chairman from it’s ranks. This is currently done a couple of months after the board election, to give the new board a chance to get to know one another. The board also appoints executive officers for the corporation at that time.

The board meets by conference call and IRC chat monthly. The agenda is published privately to the Membership. All corporate officers make a monthly written report to the board, and every Project Management Committee (PMC) makes a quarterly written report to the board. In this way, the PMCs report directly to the board, not to the President or other corporate officers. All ASF Members and invited guests are welcome at board meetings, except during very rare executive sessions of the board.

Currently, the average monthly agenda includes 10 corporate officer reports, 40 PMC reports, and often a handful of official resolutions. To ease the review process for reports, reports are due well before the meeting begins, and many directors “preapprove” reports by initialing them in the agenda file before the meeting. Each PMC report is assigned a director to serve as “shepherd” for the month; any questions raised before or during the meeting are taken by the shepherd back to the relevant officer or PMC for an answer or resolution. PMCs that report late or where serious questions are raised during the meeting may be asked to provide an additional report at the next monthly meeting.

The President is responsible for managing the day-to-day operations, and helps to coordinate the work of the VP, Infrastructure and the sysadmin team; however VP, Infrastructure also makes a monthly report directly to the board. In this way, the board exercises oversight over all official Foundation activities.

Legal

Article V. of the ASF bylaws specifies a Board comprised of 9 Directors, elected annually by the ASF Membership. The Apache Board is much like the board of directors of any other corporation, responsible for “…management of the corporate assets (funds, intellectual property, trademarks, and support equipment) and allocation of corporate resources to projects.”

The board is responsible for appointing any officers of the ASF, including executive officers – President, Secretary, Treasurer – and other officers, both those with corporate functions (Legal, Publicity), and Vice Presidents of individual Apache projects. The board also sets overall policy for Apache projects, or in many cases, delegates the details of policy setting and implementation to specific corporate officers. Official resolutions are used to appoint or change officer positions, create new Top Level Projects (TLPs) or retire unused projects, and in certain cases to make fundamental policy decisions. Most policy is simply agreed upon by the board and any relevant officer(s), and published on our website.

Communication

With the exception of monthly conference calls, board communication is done over private mailing lists. The board@apache.org mailing list is the primary place where official business is done. All directors, corporate officers and PMC chairs are expected to subscribe to this mailing list and track issues relevant to their areas of responsibility. Many ASF Members also participate, comment, and help resolve issues where appropriate.

Directors will regularly read and participate on various project mailing lists when a board-level issue or question has been raised. This participation is done wearing their board hat: i.e. as a strategic voice, addressing broad ASF policies or important community health issues. Directors participate technically in Apache projects as individuals: directors are not automatically granted committerships, PMC memberships, or even binding votes on any project matters. Directors wishing to influence the technical work of a project must gain merit and be voted in as a committer to that specific project like any other contributor.

Meetings

The board exercises oversight of Apache Projects by reviewing project reports at the monthly board meeting, and by explicitly approving all changes to PMC membership. When PMCs have voted in and nominated a new committer to serve on the PMC, they ask the board for an ACK, or acknowledgment, of the addition. Once any one director sends an ACK email, the official PMC membership roster is updated after a 72 hour wait, designed to give other directors a chance to comment or question the appointment before it is officially recorded.

PMCs are expected to provide accurate and thorough reports to the board of their community health and technical and software release activities. Projects that do not report or have serious issues in their report will be contacted by that month’s shepherd or another director to find a resolution. In extreme cases, where a PMC is dysfunctional or is not following required Apache policies, the board may unilaterally make changes to the PMC or may dissolve a project to correct the issue.

Merit

Board elections are held annually; currently, each board seat is for one year, so all 9 directorships are voted on annually. ASF Members are eligible to nominate people for board seats as well as to vote in the board election. Director candidates run individually, and Member votes are currently cast by Single Transferable Vote (STV). All nominations, position statements, and voting are conducted electronically either over private mailing lists or using our own software for casting votes. Individual votes are kept anonymous, although the full STV calculations are published privately amongst the Membership.

In the past, only existing Members with some history within the ASF have been nominated. While the bylaws allow for any person to be nominated for the board, the amount of trust and expected experience with the Apache Way for directors is such that nominees outside of the existing Membership are unlikely for the time being.

For the first several years after incorporation the board was quite stable, with a majority continuing to serve repeatedly. As the ASF grew in membership around 2004, the board began to change somewhat, with a few new faces appearing each year. Jim Jagielski, one of the founders of the ASF, has remained on the board since it’s beginning.

Directors are expected to serve as individuals on the board, representing the Membership and acting in the best interests of the ASF as a whole. Directors are expected to disclose any conflicts of interest they may have due to their current employment, and recuse themselves when necessary from votes or potentially discussions on subjects they have a conflict with.

Community

While Directors participate in a variety of communities both within and outside of the ASF, the primary community home for directors is the Membership. Most directors follow the main private Members mailing list, where any ASF Member start discussions about a wide variety of topics, spanning from new technologies, policy ideas, questions about project communities, or even personal announcements of weddings and births.

From time to time Directors participate in the communities of various Apache projects when a board-level issue or question is raised; however they do so wearing their individual Director hat. Many Directors are separately committers or PMC members on a variety of Apache projects, where they do technical and community work just like any other committer, wearing a committer hat.

Many Directors also serve in the public community; serving as spokespeople for the Apache Way or granting interviews about the ASF or our projects, or reviewing other open source or charitable foundation works.

Technical

The board does not provide technical direction for any of it’s projects or activities. The board does set broad policies – for example, requiring that all source control systems are run on ASF hardware, and controlled by ASF Infrastructure. Technical direction – either in terms of how to implement infrastructure or what code projects should work on is all delegated to the PMCs or relevant officers.

While this may be a surprise to some, it is a key reflection of how the ASF is intentionally structured to provide maximum freedom to it’s projects. The board and the ASF are happy to provide a home to any software project communities that are willing to follow the Apache Way. The mission of the ASF is to provide software for the common good: we are happy to help like-minded communities to provide that software; are confident that communities will form around software that is useful; and understand that there are many different ways to effectively and collaboratively build software.

Resources

• Bylaws of the ASF
• List of current Directors
• Board Meeting Calendar And Past Minutes
• History of Past Directors
• List of ASF Officers
• How the ASF Works: official documentation

People

• Committers (any project): 2771
• ASF Members (active): 370
• iCLAs on file (from any contributors): 4162
• PMC Members (all top level projects): 1788

Communities

• Apache Top Level Projects: 96
• Apache Incubating Podlings: about 60
• Apache Labs (experimental projects by committers): 32
• Apache Attic retired projects: 16

Code

• SVN revisions in public repo: r1165340+
• Lines of code: tens of millions++

Websites & Mailing Lists

• Web stats: http://people.apache.org/~henkp/analog/
• Mailing lists and SVN commits graphs: http://www.apache.org/dev/stats/

Users

• End users: countless.
• Web sites powered by Apache http Server: more than half worldwide
• People with Apache software on their computers: countless [1]

Corporate

• Directors: 9
• Vice Presidents or Executive Officers: 103
• Annual Budget: USD600,000+
• Corporate Members: 0 [2]
• Corporate Sponsors: 22+

[1] As a single example: Apache Xalan and Apache Xerces are shipped as the XML reference implementation and processing stack in virtually all Java installs.

[2] ASF Membership, Committership, and PMC membership are only granted to individuals who have shown merit within the respective Apache community, as voted on by other Members or PMC members within that community.

The ASF is grateful to the many corporate sponsors who pledge financial assistance or provide bandwidth and other infrastructure needs! However technical and organizational decisions in Apache projects or within the Foundation itself are always made by the individuals within that community.

Along with participating in Apache projects and in various organizational ways within the ASF, director candidates typically write a brief (or not so brief) position statement about what their objectives as a director are. These position statements are included in the board ballot that all active Members of the ASF vote on to elect a new board.

Re-reading my position statement, I’ve realized that there’s nothing I’m discussing in my position statement that I wouldn’t mind posting in public – in fact, the more I think about it, this is something I should post in public to try to better explain just how Apache works. As the ASF grows, it becomes more and more important for Members to explain how the ASF works and why it’s core values and the Apache Way are important to us.

Shane Curcuru (curcuru)–Director position statement –v1.1

=============

My mission statement for the ASF

“The mission of the ASF is to provide high quality, open source software for the public good at no cost, and to showcase our meritocratic and community-driven method of building sustainable software projects.”

http://shane.curcuru.name/blog/2009/04/what-i-believe-asf-mission/

Why you should make me your first choice

Because you believe we need to understand the global community in which we interact, while still keeping our neutrality, our public mission, and our projects foremost in our minds. Because you believe in community over code. Because you believe in keeping hats separate, our communities public and open, our organization as simple as feasible, and in making it as easy as possible for our healthy communities to build great software. Because you want board members who recognize the need to work together productively.

My objective as a director and as VP, Brand Management is to provide our projects with the support they need to ensure that our organization and our projects can continue as independent and healthy communities for the long haul. Ensuring that we can control our public perception – our brands – without commercial influence is crucial to ensuring our PMCs and the ASF as a whole remains a neutral place where all contributors are welcomed and can participate equally, and where PMC decisions are made for the benefit of the project itself.

My vision for the ASF

My ideal ASF is a respected, innovative, and neutral collaboration ground for communities and software projects. It’s a place where hobbyists, consultants, and developers from $bigcos collaborate together – easily, freely, equally and openly – building high quality software usable by all. The ideal ASF is known as a place that community-minded software projects can easily join, and that provides a rich technical infrastructure to facilitate the development process.

Our value to the world includes our software products, our community and consensus-based approach to software development, and the way our proven record of success has increased the global acceptance of open source products as a whole.

This past board has worked together well and has been very effective at finding consensus without rancor in the face of some significant challenges. As the ASF grows in members, projects, and technical influence, it is important to be able to keep true to our ideals and still maintain our friendships and respect within the membership.

About Shane

I recently had my 20th anniversary at IBM, where I work in the HR division as an Applications Architect. My employment and income have been unrelated to my work at the ASF for many years, and I will always clearly separate volunteer work from employer-funded work.

My involvement in the ASF is driven by a belief in, and a love of, the ASF, and is not influenced by politics or finances. I live in Arlington, MA with my wife, young daughter, and 2 cats. I view directorships and officer positions at the ASF as serious commitments. I will continue my attendance at every board meeting if re-elected.

Most importantly, my daughter Roxanne asked me to mention that you should vote for me because I’m the best dad ever. (unsolicited quote!)

Addenda – Public Work

I truly believe that we should work in as public a manner as practical, for public work is a key enabler of healthy and growing communities. As the ASF has grown in size and impact on the software world, it is clear that we do need to keep some specific discussions private, especially discussions on various legal matters.

In that light, I am publishing this statement on my blog in this posting.

• It’s official – here’s Oracle’s announcement on “Statements on OpenOffice.org Contribution to Apache“.
• A key thing to read is the official Foundation blog posting on “Incubation at Apache: What’s it all about?“
• Bertrand recently wrote how “Becoming an Apache project is a process, not just a decision“.
• Key reminder: Incubation is a process, with many checkpoints. Just because something is submitted to the Apache Incubator does not mean that the Incubator PMC will accept it as a podling. And once we do have a podling, the most important work comes, proving that there can be a healthy community around the project – all before it can even be considered to graduate to a Top Level Project at Apache.
• Newcomers to Apache may want to review the Apache Community Development project – think of it as an outreach group within the ASF, starting work on explaining to newcomers what the Apache Way is about and where to find the right information on technology and community rules at Apache.
• Reading Planet Apache is a great way to see what many of the committers at the many Apache projects are saying on their personal blogs.
• I almost forgot! The best way to learn about how Apache works is to read our mailing lists. You can follow along the Apache Incubator’s discussion yourself, right on general@incubator.apache.org!

Personally, I think one of the most important differences between a potential “Apache Office” podling and the existing (and amazing) LibreOffice product is the license. Obviously, both codebases are fairly similar, and aim to provide a fully open source office suite. It will be interesting to see, after the first wild set of commentary flies, which project – and which license – that various developers and corporations alike choose to actively support with their contributions. I just hope that this license difference – and the way that the OO.o code came to Apache, which was not something we controlled – doesn’t cause any unnecessary friction between the two communities.

I’m glad that The Document Foundation, home of LibreOffice, has spoken out on this donation as well.

And a great external view of the submission comes from Ed Brill, saying “OpenOffice moving to Apache, good news for the desktop productivity market“, and similarly IBM’s Bob Sutor writes his own “Remarks on OpenOffice going to Apache“.

Ooooh, Rob Weir has an excellent “Invitation to Apache OpenOffice” as well! Great reading in there, especially about some other famous Apache projects.

• Welcome to the Apache Libcloud project – “a standard Python library that abstracts away differences among multiple cloud provider APIs.”

The Apache Libcloud graduation does bring up an important point about Apache project governance and the Incubation process. Apache is happy to host any community-driven projects that wish to use the Apache license and follow the basic Apache Way. This includes potentially competing technologies. In fact, the Apache Incubator currently has 4 other podlings currently that all deal with cloud API abstractions in one way or another!

• Apache Deltacloud – a REST-like interface allowing common operations across multiple cloud providers – is the most obvious technical competitor to Apache Libcloud.
• Apache Nuvem is a podling attempting to put a higher level of data and operation abstraction atop cloud APIs, for a slightly different programming model.
• Apache Whirr is aiming to provide a level of service abstraction for multiple cloud providers, perhaps allowing your Apache Cassandra, or Apache Hadoop related projects to easily move about the clouds.
• Apache Tashi goes further along the services model, focusing on providing Apache Hadoop and big data processing services that can be pushed to the clouds.

Sound crazy to have competing technical projects? Not at all, once you realize that Apache is all about the communities behind our projects. As a public charity, Apache’s purpose is to provide software for the public good. The way we have found most effective to do that is to allow any healthy communities to compete and grow independently, within the general Apache way. We’re happy to have multiple communities working on the same kind of technology, and all the better if they can each succeed at finding their niche, both for the software they provide, as well as for the community they can build.

This also points to the special place that the Apache Incubator has at the ASF. Bertrand has an great post discussing some of the whys and hows of the Incubator, and the process that new communities (and their projects!) go through before becoming a top level project at Apache.

• Submit your ideas now for the CFP of ApacheCon NA 2011 – coming to Vancouver this 7-11 November. CFP submissions are open through April.
• Welcome Apache Extras! Apache Extras is the the place for all your Apache-related software that’s not an Apache project. That means that projects that might not use the Apache license or might not meet the community criteria for formal Apache projects, but are still related to Apache technology. Apache Extras gives you all the infrastructure support of Google Code, and shows your project’s interest in Apache technologies.
• Welcome to our new Executive Assistant! The ASF has hired an EA to assist with a broad array of administrative tasks, who is already helping out with our conferences and other corporate operations.
• We’ve got new top level projects! Over the past few months, the Incubator has graduated the following projects:

• Apache Thrift is a scalable cross-language framework for code generation between a wide variety of popular programming languages.
• Apache ZooKeeper, an Apache Hadoop spinoff, provides a centralized service for providing distributed synchronization of configuration information and other services.
• Apache OODT (press release) is middleware for managing data used in critical scientific applications – and features original code and contributors from NASA and the JPL. Yes, real rocket scientists work on OODT!
• Apache ESME stands for Enterprise Social Messaging Environment, and allos for secure and scalable microsharing and micromessaging applications.
• Apache Aries implements the EEG’s enterprise OSGi specification for multi-bundle applications.
• Apache River implements JINI services and allows construction of secure and distributed systems.
• Apache Chemistry (press release) is an implementation of the OASIS CMIS standard, allowing access to a wide variety of different vendor’s CMIS repositories.

There were several other interesting happenings in Apache land recently as well.

• Apache UIMA and Hadoop technologies helped IBM’s Watson supercomputer defeat humanity in the TV game show Jeopardy! As one of the human contestants wrote: “I, for one, welcome our new computer overlords.”
• The Apache Subversion project issued an open letter to a corporation who is an active contributor and user of Subversion. While this is an unfortunate situation of a third party effectively usurping some of the good will generated by the Subversion project itself, the issue is being addressed, and it looks like we’ll have a productive resolution. This underscores the importance of appropriate governance and trademark protection for open source projects.
• Separately, those interested in using Apache projects may be interested in a number of much more detailed trademark policies that the ASF is working on, in an effort to make it simpler for third parties to associate with our projects, while ensuring that our project communities get full and proper credit for their work.

• Apache Third Party Domain Name Branding Policy – where the Rationale is an important explanation of why our trademark policies are written as they are.
• Apache Third Party Event Branding Policy
• Note that we are working on a Services Branding policy which is expected to be similar to the Domain Name policy as well, for those who wish to host services using our marks and software.

Trademarks, you say? Isn’t that some complex legal stuff that big companies care about? Well, yes – it’s certainly complex law – but you should care about it too. Think of a trademark as a pointer to your project’s reputation. A trademark is the symbol that represents your project’s reputation, and associates that name with your product in the minds of the consumers. In both cases, the community behind the project is paying attention to branding for the project – and working to ensure that control over the project’s name stays with the community, not a commercial company.

Trademarks ensure that consumers – in our case, either end users or developers – know where the Foo project comes from, and know to come to the correct Foo project to participate and get the code. You may have the best Foo in the world, but if no-one knows about your Foo (or it’s name), then it’s had to attract much interest.

This is a key reason for Apache being a non-profit corporation (likewise, a reason for many other truly community-led open source foundations). The Apache Software Foundation controls the trademarks associated with it’s projects, and manages them for our projects. As a vendor-neutral organization, the ASF can ensure that ownership of our trademarks stays with the larger Apache community, and can’t be co-opted by a commercial entity.

Apache’s trademark policies are posted publicly. We have guidelines for how our PMCs should represent Apache marks on our sites, and are working on important updates to the Apache Event Branding policy.

Another good resource on trademarks in open source is Passport Without A Visa: Open Source Software Licensing and Trademarks. It’s worth learning enough about trademarks to ensure that you consider it for any new projects you work on. Note, however, that trademark law is complex, and many of the answers to trademark questions are “It depends”. Thus it’s always recommended to consult legal counsel if you have serious questions about trademarks.

The Executive Committee is clearly not a Committee of Executives, nor is the Java Community Process a Process involving the Java Community.

I applaud everyone who has done technical work on recent versions of Java, and I’m sure plenty of people will still want to program in Java. That’s great. But please – when you do use Java, please remember that it is *not* built on open standards. It is built on technology (and patents) and licenses that Oracle controls, and is quite happy to exercise it’s control over all things Java.

If you’re happy paying Oracle more and more licensing fees in the future, more power to you. But if you’re not, then you really need to understand the problem of the TCK Trap.

Stay tuned for more updates from the ASF’s Foundation blog on what this means for the many many excellent Java based Apache projects. And, follow the #jcpisdead hashtag to understand what impact it may have on your Java future.

For more reading, follow my set of ‘oraclemess’ Delicious bookmarks.