Tag: apache

Thanks to the Apache CloudStack community!

Apache CloudStack graduated to become a top level project at the ASF last month, and a number of community members have been blogging about their experience. CloudStack started with a company called Cloud.com, was purchased by Citrix, and then was submitted to the Apache Incubator last year to now become a full Apache project.

Along with the great CloudStack software that Apache can now provide that allows you to manage your own public or private IaaS clouds, the Apache community has gained a great new community of committers, users, and PMC members.

In reading the several blog posts by key CloudStack contributors, I reminded myself that kudos were in order as well.

Having watched Citrix bring their code and developers to the Apache Incubator, and having watched (and commented on and answered many questions from!) the podling as it grew it’s community and graduated, I’ve been struck by how well the core Citrix contributors and their many other participants really took to the Apache Way.

Both Citrix as an organization (which employs some of the CloudStack committers), and especially the many contributors to the CloudStack project took the incubation process seriously, and have really gone above and beyond to ensure their podling proposal and march to graduation have been about Apache CloudStack, as well as being about an inclusive and meritocratic project.

The desire to get things “right” at Apache was clear in everything the CloudStack community did, and the end result looks to be an incredibly strong project that’s quickly gathering developers from a wide variety of vendors and users. Part of this growth is about the great technology; but a lot is due to the helpful and welcoming face that the CloudStack committers put on their project.

We’ve had a lot of great projects, and many great communities come to the Apache Incubator; there are a lot of people to thank across the tremendous spectrum of no-charge software that the ASF provides for the public good. But I just wanted to mention the extra effort the CloudStack community put into fully embracing the Apache Way. Good job, and thanks!

Thank you to my Apache family

My father Steven passed away recently after a short and painful bout with pancreatic cancer. Along with a few old friends of his, many of my closest friends called or visited to help organize matters as you might expect in a situation like that. Similarly a very large number of Apache members wrote quite heartfelt emails of support and condolences.

But what struck me the most – surprised me, actually – was the knock on the door from the flower delivery. It took me a moment to realize that the ASF had sent me condolence flowers directly!

I had listed “in lieu of flowers” in the original death notice, so I wasn’t expecting anything like that. It was quite a pleasant surprise, since it was just the right kind of thing to cheer up the house at that point.

More to the point, it underscores how important community is at Apache. Not only do I know I can count on the individual support of the many friends – much like family – that I’ve met there over the years, but the ASF as an organization has a heart for it’s membership and individual contributors as well.

In any case, many thanks to my Apache family.

Obligatory note: I’m also looking forward to seeing many of my readers at ApacheCon NA in Portland, OR next week! I’ll be giving a talk on open source branding, along with many many other Apache family members.

P.S. No disrespect nor allusion to any Native American Apaches or related persons or tribes is meant.

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

Shane’s Apache Director Position Statement

The ASF is currently holding it’s annual Member’s meeting, where we elect a new board of directors among other matters (and usually elect a number of new ASF Members!) I am fortunate enough to have been nominated again for the board election, something which I am truly grateful for.

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.

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

Apache Office, anyone?

I imagine there will be a lot of news – and commentary – and, ahem, heated discussions about today’s submission of the OpenOffice.org codebase to the Apache Incubator by Oracle. Here are a few handy links and thoughts that may be helpful to ponder:

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

Apache projects are independent and non-commercial

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

While not all aspects of the Apache Way are practiced the same way by all projects at the ASF, there are a number of rules that Apache projects are required to follow – things like complying with PMC release voting, legal policy, brand policy, using mailing lists, etc., which are documented in various places. There are a few rules that I think may not be documented as succinctly as they should be.

A primary purpose of the basic requirements the ASF places on its projects is to help ensure long-lived and stable projects by having a broad enough community to maintain the project even in the potential absence of any individual volunteer or any sea change at a major vendor in that area. The Apache project governance model is explicitly based on a diverse community. This is different from other governance models, like the “benevolent dictator” idea or the often corporate-backed model that Eclipse uses.

Apache projects are independent

This is implicit in the fact that the Project Management Committee (PMC) runs the project and the fact that PMC members are expected to contribute to the project as individuals, wearing their “PMC hat”. The concept of hats means that when a PMC member votes on project matters, they are casting their vote as an individual acting in the best interests of that PMC, and not as an employee or representative of some third party. There are also certain expectations of diversity within a PMC; the board may apply extra scrutiny to PMCs with low diversity (i.e. PMCs that are dominated by people with a common employer). Similarly, the ASF does not allow corporations to participate directly in project management, only individuals.

There are two important aspects to this independence: project management, and project use by end users.

Apache projects are managed independently

Apache projects should be managed independently, and PMCs must ensure that they are acting in the best interests of the project as a whole. Note that it is similarly important that the PMC clearly show this independence within their project community. The perception of existing and new participants within the community that the PMC is run independently and without favoring any specific third parties over others is important, to allow new contributors to feel comfortable both joining the community and contributing their work. A community that obviously favors one specific vendor in some exclusive way will often discourage new contributors from competing vendors, which is an issue for the long term health of the project.

Apache products may be used independently

All Apache projects must release their code under the Apache License, which clearly specifies the minimum restrictions that users of Apache software must agree to. Apache software is all about being able to use it for virtually whatever our users want – open source, proprietary, secret – we’re happy to have users take our software (although not our name) for virtually any purpose. While our legal guidelines allow certain other software licenses to be used for specific dependencies, the software we release always uses our license.

Extending this idea, users of Apache software should be able to find our software, learn how to use it, and actually apply it to all its common use cases solely by going to the Apache project’s own website. Apache projects should provide sufficient documentation, install features, basic user help (through mailing lists) and services for the common use cases to the user, without them having to rely on third parties. It is important that our users can both make use of our software freely – both in terms of not having to pay for the software, as well as not having to worry about IP claims or other more restrictive licenses on either the software or the configurations or other common materials required to actually use the software.

Apache projects are non-commercial

The ASF’s mission is to produce software for the public good. All Apache software is always available for free, and solely under the Apache License. While our projects manage the technical implementation of their individual software products independently, Apache software is released from the ASF and is always meant to serve the public good.

We’re happy to have third parties, including for-profit corporations, take our software and use it for their own purposes – even when in some cases it may technically compete with Apache software. However, it is important in these cases to ensure that the brand and reputation of the Apache project is not misused by third parties for their own purposes. It is important for the longevity and community health of our projects that they get the appropriate credit for producing our freely available software.

 

 

Reminder: “The postings on this site are my own and don’t necessarily represent positions, strategies or opinions of either my employer nor the ASF.”