Shane’s Apache Director Position Statement 2012

The ASF is holding it’s Annual Member’s Meeting this week, where the Membership elects a new board of directors along with other matters, like voting in new Member candidates. I am truly fortunate enough to have been nominated again for the board election, in this case by one of the founders of the ASF (JimJag). Along with believing that I can do a great deal of work to help the foundation and all Apache projects as a director, I also have to say that I have a lot of fun serving on the board. Yeah, I’m a little funny that way in liking doing all the organizing work behind the scenes.

Director candidates at the ASF write position statements about what their objectives for being a director are in preparation for the voting process. Since I write what I believe in, I also am posting my statement here, publicly. One of the biggest issues for the smooth functioning of the ASF as a home for healthy projects is doing a better job of explaining how we work – I hope this helps people understand us Apache types just a little bit better.


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

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/

Objectives as a Director

My objective as a director is to prevent unnecessary drama and help the ASF and all Apache projects work more smoothly by:

  • Acting as a calm, moderating, and explanatory voice on the board, and working to improve the board’s communication style,
  • More clearly documenting and publicizing the very few rules and requirements that we expect of Apache projects,
  • Better explaining and educating our project communities on the very many best practices and suggested guidelines we have.

I’ve learned a lot in the past few years on the board. A key lesson is that we need to minimize the number of hard rules that we have for our projects to those that are truly
requirements. We also need to much more clearly explain those rules and educate our project communities about them.

Likewise, we have an immense amount of best practices and great guidelines for running successful, collaborative projects that we’ve proven are helpful over and over again. More clearly presenting these as guidelines to our project communities and to the world at large will help all of our projects to succeed.

We’ve often said the board is a blunt instrument – but I believe that we’re experienced enough and a large enough organization that we don’t need to be. There are a number of times in the past years where the effect of the board tromping in to fix a project issue has been… unfortunate. With more professional communication and with better explanations of the rules and guidelines we expect Apache projects to follow, we can resolve project issues – and provide better advice to projects when they ask – with much less drama than we’ve had in some cases in the past.

We have immense collected wisdom on managing community led projects within the membership and the excellent director candidates for this year. It’s time to ensure we make this wisdom accessible to both our project communities and to potential contributors by better documenting it and presenting it, rather than waiting until after an issue arises and then explaining “you’re doin’ it wrong!”

Common Questions

Some members have been discussing a handful of questions about what people think about the future of the ASF, and some of our key projects and technologies, which I’ll comment on in some general ways.

The Apache Incubator is probably the most important project at the ASF today. It is where we should be teaching new podling communities both what is expected behavior and processes for Apache projects, as well as mentoring new communities on effective ways to build consensus-driven and community-built software projects. While the Incubator has been doing OK for a while, there is a lot of room for improvement. Luckily, both with Jukka as the new chair and a number of new, energetic members thinking through improvements, things are looking great. I’d encourage the IPMC to continue to simplify and normalize the sometimes wordy, pedantic, and all-over-the-place documentation for podlings – and especially to continue the great report review process changes that Jukka has begun. Similarly, we need a strong focus on ensuring that Members who sign up to mentor new podlings are truly showing up and working with their podling communities.

This is actually one of the most crucial areas that Apache Members can help. Both in terms of mentoring new podling communities within the Incubator, and in terms of helping to keep an independent and wise ear within our existing TLPs, Members are the personal element to the shared tribal knowledge of the Apache Way. Fundamentally, individuals will do what interests them; however I believe with some effort on clearer documentation around best practices, and especially some patience and effort at remaining calm and polite in our discussions (both privately and publicly), that we can improve Member activities within projects. In particular, this is a place where we need existing members to step up and provide strong mentoring to the various new Member candidates I expect will be voted into the ASF at this week’s meeting.

Discussions around new tools and arguments about technical merits don’t usually interest me that much. What does interest me is ensuring that we work to provide the tools that our projects responsibly ask for, and that for all of our tools we:

  • Ensure we have a reliable capacity to maintain the tools with our own existing infrastructure (people and servers). It is important that the ASF is in control of the tools and servers that our projects need to continue their work, since we’ve seen issues in the past where, even with the best of intentions, third parties maintaining tools for us just doesn’t work in the long term.
  • Ensure that the ways the tools are used truly supports consensus-driven and community-built software projects, in ways that keep our projects functioning as true collaborations of a community, and not just a collection of individuals.

Greg Stein – another existing Director who’s nominated for another term – came up with a great objective: to create a Foundation that can live for 50 years, hosting healthy projects. I love that idea. I think we already have the start of that, however some key things to think about are:

  • Better documenting and mentoring new members and new communities on the core values of the Apache Way. As we grow, it’s harder and harder to convey the tribal knowledge that many of our members share organically; it’s time to be more consistent at educating newcomers to all of them.
  • Much more clearly document the minimum required rules that we need to operate. I say minimum, because these should be limited to only what we truly need; however there are plenty of corporate procedures that we know how to do, but may not have written down for the next decade’s set of officers and directors to learn from.
  • Continue to evaluate new tools, methods, ideas, and incoming communities to see how we can grow and improve upon our core Apache Way – all the while without losing our way. The ASF is not a place for all projects; we have a clear ethos around how to build and distribute software that we should not bend. But there are improvements we can make to ease the way for communities of developers who do share our core values.
  • We need to get better and more frequent feedback from our regular sponsors, since their recurring donations are critical to keep our independence – through the infrastructure, press, and other services those funds allow us to provide to all Apache projects. This is never to say that sponsorship dollars ever translate into technical influence. But for many potential sponsors, it’s both what we do and how we present ourselves that is important.
  • We need to ensure that as we grow staff positions (infrastructure and other contractors) that we are careful to keep our policy decisions thinking about the future Foundation, hosting projects full of volunteers; and our paid staff and officers focused on execution.

Some members have asked about legal and trademark issues. These are both areas that work differently than our Apache projects, in that much of the work is necessarily done in private lists. This often makes it more difficult for people to understand how comfortable they are with what’s happening (even though all Apache Members are always welcome to review any mailing list, even private ones).

In both the legal and trademark areas, I agree with most directors that we have delegated execution of these areas to the respective officers (disclaimer: I am the current VP, Brand Management), and that I trust those officers will responsibly manage their affairs. I’m confident this will work, and that we’ll be able to find the resources needed, both because I know the officers, and because we have a solid and monthly reporting that the board reviews and discusses regularly. Our Conferences Committee has had some issues in the past year or so with burnout (planning ApacheCon takes a lot out of people – as I and a dozen or so other Members know far too well). But we have a new VP in the form of Nick, and some great energy from a number of new volunteers in that space, so I’m confident that while ApacheCon may be a little bit different in years to come, that it and the many other BarCamps and smaller events we’re lending our brand to will be successful in bringing newcomers into our communities.

Many members have varying opinions on growth: how much should the ASF grow, how should we grow, etc. I recently wrote about this in my set of slides About: Apache, where I reviewed the ASF and the Apache Way. A key part of my slides is: the ASF doesn’t have a technical agenda. “Apache” doesn’t have a top-down list of projects or technologies we want to “acquire”. The ASF exists to provide a home for like-minded communities who build software. While I hope that my work on Apache branding and work on improving documentation about the ASF and Apache projects helps new communities understand who we are, I don’t personally plan to directly “recruit” new projects. If people ask, I’m certainly very happy to tell them about the Apache Way, and why I think it’s so cool – but I’m not looking to proselytize.

Officers and Directors

If elected I will not accept any new officer positions this term, unless the new board wishes to appoint me Chair/Vice Chair.

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.


Reminder: “The postings on this site are my own and don’t necessarily represent the positions, strategies or opinions of my employer nor of any volunteer organization I work with.”

CamelOne 2012 Presentation – About: Apache

I was recently asked to speak at the CamelOne conference here in Boston, about The Apache Way. Here are my slides (including my speaker notes, written today).

TheApacheWay-ShaneCurcuru-CamelOne2012

This presentation is placed under the Apache License, v2.0, and was created with Apache OpenOffice v3.4 Impress application, and uses Open Sans fonts, also under the Apache License. This is not to say that I use only the Apache license, more to point out that there are plenty of different kinds of resources available today under the Apache License.

If you have suggestions, questions, or comments about this or anything else Apache, please let me know! Even better, ask about it on the Apache Community Development Mailing Lists!

Many thanks to Jim Jagielski and Justin Erenkrantz, who’s past Apache Way slides I borrowed heavily from; and also many other Apache members like Lars, J Aaron and company who have given many an Apache Way talk in the past.

Apache projects are technically independent

This post has been improved and posted as guidance to all Apache projects on the Community Development website – please read the new version there!

In the earlier essay I wrote on Apache project independence (since promoted to an article on the Apache Community Development website) I missed a critical bit of independence that I think we should add to the ComDev site.

Apache projects are technically independent

While Apache PMCs provide a report of their operations to the Board on a quarterly basis, they are technically independent of the Board. PMCs are free to collaboratively decide their project’s technical direction however they choose. While the Board holds PMC chairs and PMCs accountable for ensuring that their methods are appropriate – following the Apache Way and the few other rules at Apache – the Board does not exercise any technical direction over Apache projects.

This is a critical point to understand. There is no top-down direction at the ASF in terms of what technology we implement or what kinds of projects we seek out or support. All technical choices are made by the individual committers and PMC members within their project communities – i.e. the individuals actually doing the coding decide where the coding will go.

This applies equally to the Apache Incubator, as the gateway of new project proposals at Apache. The ASF has noagenda of what projects it wants to find, nor do we have a corporate strategy for new project acquisition. Project communities that want to come to the ASF are welcome – and will be reviewed in the Incubation process for community health and diversity, and for IP clearance and licensing. But not for technical merit.

The essence is: if there is a sufficiently diverse community who chooses to live by the Apache Way, the ASF is happy to host them. The fact that there is sufficient diverse community means that people are interested in the technology. Similarly, the Apache Attic awaits projects that may seem interesting technically, but fail to have a sufficiently diverse and active community to maintain them.

So – worthy to add to the ComDev page?

Thank you, Apache Sponsors!

I just wanted to take time to say thank you to the many financial Sponsors of the ASF.
Thank you, Apache Sponsors!

Our many regular Sponsors pledge to donate a set amount of funds to the ASF annually, and they really deserve some recognition for this. While we very, very much appreciate the many individuals and other businesses who donate funds periodically, Sponsor donations do make up the bulk of the ASF’s annual income. These donations pay for things like bandwidth for our websites and software downloads, servers and racks for our million+ Subversion revisions, hundreds of mailing lists, and other services, and our crack Infrastructure contractors who keep it all running, plus a whole host of other organizational services we provide for all Apache projects.

Some news was made about several new sponsors recently: Huwawei, GoDaddy, Twitter, and Citrix at various levels of sponsorship, and we appreciate all of them.

I wanted to recognize one great quote about one of these sponsorships. Ars Technica covered one of these sponsorship announcements, and there was a very interesting comment thread following the article.

One commenter snarked, in effect, “Twitter isn’t profitable, so you’re really giving other people’s money to Apache”. What struck my eye is the very honest and right-on-the-mark reply from caniszczyk of Twitter, who replied:

As the guy who created and runs Twitter’s Open Source Office, this is spot on. We already contribute heavily to the ASF by actually committing and contributing to the projects we use: Mesos, Cassandra, Lucene, Thrift, Hadoop, Pig, Mahout and more. There are solid engineering resources committed to some of these projects, which some of them its their full time jobs.

As we evolve as a company, we think it’s the right thing to do to give back to the foundation that supports projects which we benefit so much from. As an open source guy for many many years and on a personal note, I don’t think enough companies give back.

In the end, as we grow, we hope we can give back more in the near future.

I won’t pretend that most businesses don’t take giving money away seriously, and will look for their ROI or whatever in deciding (or not) to donate funds to open source projects. But it was just one quick and very well put quote that shows the larger value of the great software the many Apache projects put out that benefit thousands of businesses every day.

Thanks, sponsors!

Apache Governance: Membership

This post has been improved and published on the ASF’s website as the Governance overview of Membership – please read it there!


This is the third in a series of essays describing Apache governance. The ASF is a non-profit, membership-based corporation; as such the Members of the ASF have a role similar to shareholders in a publicly traded corporation.

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 membership, 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 measurable time, but without making it obvious that you’re seeking recognition.

Candidate members are voted on as a simple majority vote (more yes’s 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 an 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 of 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 Apache 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 its 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 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

Apache Governance: Project Management Committees

For the latest on what Apache PMCs are and how they work, please see the updated version of this on the official Apache Governance Overview of PMCs!


This is the second in a series of essays describing Apache governance. Fundamentally, the most important organization at the ASF is a PMC or Project Management Committee. These are the actual groups that decide what software our projects release, and as such do the bulk of the actual work of the ASF.

Continue reading Apache Governance: Project Management Committees

How To Pack For ApacheCon NA 2011

Don’t forget your passport!

  • Airport: YVR
  • Getting to the hotel: VancouverTips
  • Local Google Map of Hotel
  • The Westin Bayshore is the conference location
  • The conference sessions/expo will all have an ApacheCon wifi network available all day. Wifi is available in hotel rooms for an extra charge.

Conference schedule and discussions:

Social Networks:

Official @ApacheCon twitter feed.

Apache Governance: Board of Directors

This post has been improved and turned into the ASF’s official Corporate Governance overview of the Board!

This is the first in a series of essays describing Apache governance. While there are a number of existing documents that explain some of the “hows”, I’m hoping to fill in some of the key information about the “whys” of how the Apache Software Foundation (ASF) actually works day-to-day. Look for more articles on things like the Membership, PMCs, projects, and more coming up!

Continue reading Apache Governance: Board of Directors

+1 Friend ApacheCon NA 2011!

ApacheCon is coming up soon – 7-11 November this year in lovely Vancouver, BC. Be sure to make your travel plans soon, especially for any US travelers who need to remember that we’re in Canada this year!

Is ApacheCon on your friends list? Let others know you’re attending by friending or signing up on your favorite social network:

Even better, you can now +1 ApacheCon postings on Google Plus. Talk about the “+1” phrase coming full circle back to the group that popularized it years ago!

Apache by the Numbers

With credit to the many. many folks who have written nice stats collection code – a review of what the ASF is by the numbers.

People

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

Communities

Code

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

Websites & Mailing Lists

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

[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.