When push comes to shove and full consensus on governance matters at the ASF or at Apache projects isn’t easily found, it’s important to consider what our underlying objectives are. The mission of the ASF is to produce software for the public good. That’s a good start, but like many concise mission statements, it doesn’t tell the whole story.
There are several aspects of how we expect Apache projects to work that we believe are critical to our mission’s success and longevity. These include things like The Apache Way of: volunteer and collaborative led community built software projects; using the permissive Apache license; and having a consistent and stable brand, infrastructure services, and home for all Apache projects.
We – as in the bulk of the Apache membership and especially the directors that we elect to the board (and thus the corporate officers the board appoints to set policy) – believe that these few core organizational and community management principles are so important for our long term mission that we require these behaviors of all Apache projects. Part of having a consistent brand is showing some level of consistent behavior with the products you produce. Having a shared set of infrastructure services likewise simplifies the process for users to find and use our products. Using the permissive Apache license means that we give maximum freedom to the users of our software, meaning that more users are likely to choose it.
But beyond these core principles, ones we have carefully crafted through experience working on Apache projects and have attempted to minimize when prudent, how do we decide where the ASF should go in the future, or what other, more detailed principles might be important to us? While the officers and directors set the official policies of the ASF as an organization, we look to the constructive input of all Apache members when discussing these ideas.
One recurring meme when discussing “What else should the ASF be/do” has been: “Projects first, or Foundation first?” I.e. is the ASF here to serve the needs of our Apache projects, or have Apache projects chosen to come here to follow the direction of the ASF? Should the ASF decide what kinds of projects we want to join, and decide The One True Technology; or should we simply see what projects show up, and try to support them?
If you picture Eclipse, you can see an example of “Foundation first”: the Eclipse board and leadership – mostly through it’s paying corporate sponsors and de facto corporate-led projects – has an overall vision and drive that explicitly provides direction for it’s projects. Eclipse has full-time staff devoted to “…1) IT Infrastructure, 2) IP Management, 3) Development Process, and 4) Ecosystem Development.” Similarly, the Eclipse board is partially made of appointed members from their Strategic Developer and Strategic Consumer corporations. That leads to strong consistency and direction, primarily for the benefit of the corporations directly or indirectly funding Eclipse projects.
“Projects first” means that the ASF exists to serve the needs of any projects who choose to join us, and who willingly agree to follow our basic rules, like using our license, consensus-driven decisions, and running projects independently of corporations. Our mission is not on behalf of the many corporations who pay their employees to donate code to Apache projects. Our mission is to provide software for the public good – that is, the end users of our software, and the larger world around us.
The ASF doesn’t have an agenda beyond that mission. We don’t have a strategic plan for acquiring projects in specific technologies or from specific corporations. We rely on providing a stable and friendly home for like-minded individuals and communities to build software… for the public good. We certainly hope – and time has shown – that this model will attract vibrant communities that will build useful software. There are plenty of Apache Members and Committers who are passionate about sharing their experiences in software development with others, which is great. But as an organization, we don’t have a strategic plan for seeking out new projects: we believe the best process is to let like-minded projects seek us out.
To ensure that Apache projects focus on the public good, we also require our projects to be run independently of undue commercial influence. Apache projects don’t exist to serve as a vehicle for the corporations who may have donated technology or employee developer hours to them – they exist for the broader public good.
This independence is fundamental to the long-term health of our projects, and to the ASF. It both makes the ASF a place where potentially competing corporations can feel comfortable collaborating on technology (which gets us lots of software for our mission) and also seems to attract plenty of individuals who are interested in participating in our projects – even when changing employers. This independence means that an independent Apache project can continue to exist for the benefit of it’s users even if one of the corporations donating technology to it decides to change direction.
But beyond the core requirements here – ones designed to keep project governance in our independent communities – the ASF strives to not add any additional requirements, but rather to provide the best home to like-minded Apache projects that we can. So in that way, we try to remain focused going forward on putting “Projects first”.
Actually, I should amend that. We do have the core project requirements; ones associated with being an Apache project. So I should really say that we put “Apache projects first”. But beyond that Apacheness that the ASF has developed over 13 years and 190 project communities, we strive to not have an agenda – other than to support those Apache project communities who choose to join us as best we can.
People still reading may also be interested in learning how governance at Apache works.