Category: Community

Shane’s Apache Director Position Statement 2013

The ASF is holding it’s Annual Member’s Meeting this coming week, where the Membership elects a new board of directors along with other matters, like voting in new Member candidates. While I was nominated last year, I was not elected. I would have been sad about not getting a seat, except for the fact that such other fabulously good people got elected instead (including two new directors who got to serve their first terms, Rich and Ross, yay!).

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. You can also see what I wrote last year.

If you’re wondering how governance at Apache really works, I’ve written an Apache governance overview too.

Shane Curcuru (curcuru) Director Position Statement

v2.0 statement

As the ASF scales in people, projects, and impact on the world, we
need directors that can ensure our organization stays true to it’s
ideals; that can delegate appropriately and efficiently to officers
and PMCs; and especially that can communicate calmly, clearly,
and consistently in all of their communications.

As we surpass one million $ in assets, with thousands of committers, nearly a gross of projects, and an huge impact both on the software world with our technology, and on the larger world of computer users with our products, I believe it’s important to do an even better job of explaining what the ASF is about and how the Apache Way works.

While we don’t need more rules, we do need to do a much better job of explaining what our few hard requirements are, as well as showcasing the wealth of best practices that our projects have created. This is important both to let the world know who we are, and also to ensure that the many different communities of contributors can more easily understand how to work with our projects.

With the fast growing scale of our organization, it is critical that directors and corporate officers can communicate clearly, calmly, and professionally in all of their Apache related activities – whether or not they’re explicitly showing which hat they’re wearing at the moment. As our impact grows, so does the impact of our words, both inside our communities, attracting (or not) new members to our communities, and also on the larger world of corporations, universities, and other computer using peoples. Even if we as long-time denizens of members@ understand which hat a director or officer is wearing when they speak, most other human beings and most other contributors don’t necessarily see the distinction.

It has been a long time since we held in-person member’s meetings
where everyone knew each others personal style. As we grow,
we need to be sure that we’re making it easy for new members and
contributors to feel welcomed and understand how Apache works. We also need to ensure that we both can keep the sense of family and enjoyable, collaborative community that the membership and our projects have, and that we manage the affairs of the ASF and of our projects in a consistent, documented, and professional manner.

About Shane

I’ve been a committer since November 1999, a Member since 2002,
and VP, Brand Management since 2009.

I am employed by IBM 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
Massachusetts with my wife, young daughter, and 2 cats. I view
directorships and officer positions at the ASF as serious commitments.

I will attend every board meeting if elected.

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!

Apache Corporate Policies

The old saying goes that one of the last things done in many open source projects is the documentation. Taking this to the organizational level at the ASF – the corporate level – that’s both all too true, and not at all true.

Questions regularly come up across various ASF lists about all sorts of corporate operations, and there are a fair number of times when it takes a while to get the right answer to the questioner. Luckily, we have a lot of very experienced Members and Officers who are there to ensure the right thing does happen – but I believe that the answers come be a lot quicker if we had better documentation for these corporate operations. Namely, all the stuff that’s not dealing with code.

This is not to say we haven’t documented how the ASF as a corporation works: a lot of effort has gone into our standard operating procedures, and we’ve both covered the basic legalistic bases, as well as put serious thought into minimizing the absolute rules at Apache while providing lots of best practices. These procedures – and the discussions of pros and cons and whys explaining how they came to be that way – are all available… on the mailing lists, somewhere. 😉

The foundation of our corporate policies is The Apache Way. Understanding that, and understanding that the fundamental mission of the ASF is to produce software code for the public good, leads you to many of the policies we practice, both at the ASF and in Apache projects. To start with, here’s a brief laundry list of how to learn about Apache Corporate Policies.

  • Apache Corporate Governance and org chart describe organizationally how the ASF as a corporation is run. This also makes clear the distinction between organizational governance – the board, membership, and officers as a whole; and technical governance – the fact that PMCs independently manage their projects.
  • The Foundation page provides the overall corporate mission, and links to the Board and Membership pages with the nitty gritty of corporate records.
  • The apache.org/dev pages are both a generic project runbook, technical issues FAQ, and partial corporate operations listing. While these are written by committers, for committers and developers, they have a lot of great information on how all sorts of things at the ASF and all Apache projects should work.
  • Another key overview of organizational documentation is the Community Development project site. This aims to be a more human-friendly signpost to find the relevant technical widget or policy information elsewhere.
  • The Apache Incubator is another important place where proper procedures are documented: this is where we try to explain to prospective new communities how an Apache project should be run before the ASF formally accepts them.

Here are some other principles and rules we follow that are important to understand.

  • Transparency. All technical decisions on Apache projects are reflected on publicly archived mailing lists. The phrase “If it didn’t happen on the list, it didn’t happen” is not just an old saying, it’s the rule at Apache.
  • Respect. One of the primary exceptions to transparency are discussions about individuals. Votes on new committers and PMC members are typically held in private lists amongst a whole PMC, since this both allows better honesty of expression, as well as prevents embarrassment in rare cases where a nominee is not voted in (yet).
  • Organizational Oversight. While the ASF relies on volunteers to produce the code that we give away, we keep it organized by having oversight: the PMCs ensure that projects are managed appropriately; the board ensures that PMCs manage themselves, and corporate officers ensure that the ASF’s corporate bits are covered.
  • Member Oversight. Members of the ASF have the final level of oversight of the board and the corporate officers. All members are allowed to review any private mailing list within the ASF, including any private@ list for projects. Members do not receive special status on any lists; merely the ability to oversee all operations. The only exceptions are specifically restricted mailing aliases that are used for legally protected communications or infrastructure root level issues.

Note that while Members have a broad oversight ability within all aspects of the ASF’s operations, organizational matters like this kind of oversight are not transparent outside of the ASF. While we certainly strive to make public as many of the great lessons we’ve learned about governing community-led software projects, the operations of governance are kept primarily within the Membership.

Partly, this is due to all the lawyers. The details of running a million-dollar corporation require a fair amount of legal work. We strive to publish as much information as is practical in things like board minutes; however the actual corporate processes are done privately.

Partly, this is because part of a meritocracy is allowing those who do to do the work. Individuals who are trusted and useful to Apache projects are elected as committers or PMC members, and therefore can help directly govern those projects. Similarly, individuals who show wisdom and effort towards the goals of the ASF may be elected as Members, and therefore can help elect the board who will appoint the officers to ensure the ASF continues running smoothly.

A great place to ask questions about these kinds of issues is the Community Development mailing list.

Dear Wibidata: The Elephant Noticed

Astute Apache Hadoop Public Committee Members have noticed local corporation WIBIDATA’s attempt to usurp our yellow elephant project mascot. We have mobilized our sources, and I have posted an official trademark complaint on their website:


Please note that the Apache (TM) Hadoop (R) yellow elephant logo is a worldwide trademark of THE APACHE GROUP, and more to the point, the elephant is very conscious of his appearance; thus we DEMAND that you remove his image from your WIBIDATA blog post immediately, forthwith, forsooth!

As a courtesy, I am leaving you this blog comment now to alert you that our army of lawyers on howdahs have already left, and should be arriving shortly at your corporate headquarters to insist on ceasing and desisting such indecipherable designs. They should arrive within a day or two.

You may have noticed that the proper Hadoop logo is always facing to the right; we have learned the hard way that our elephant is insistent at only being photographed from his RIGHT side. Pictures of Hadoop's LEFT side tend to enrage him, so we will also be sending you a bill for the racks of servers that our normally lovable elephant mascot knocked over when he saw your picture of him being jumped on by a tortise.

Note: THE APACHE GROUP only accepts cold hard cash, or properly licensed AND formatted patches. You might also want to send some peanuts as a peace offering.

Thanks for your swift... er, eventual attention to this matter,

- Shawn Curran

Trademark Architect

THE APACHE GROUP

ApacheCon presentation: Managing Apache Project Brands

At ApacheCon NA 2013 here in Portland, OR I will be talking to a packed house about how Apache projects manage branding and trademarks, to wild applause. OK, perhaps my crowd is not likely to give applause, but I’m certain it will be appreciated.

As a preview, here is the v2.0 slides of my presentation. While originally this was going to be similar to last summer’s OSCON presentation on Managing Open Source Brands, I’ve realized that the trademarks@ group at the ASF really has a very customized approach. So the slides have a very different feel, and help to show the real difference between how projects have maximum freedom – for their own technical / branding direction – but also have maximum support – because the ASF’s corporate organization stands behind their license, their trademarks, and our servers.

Managing Apache Project Brands slides (ODP

Please do let me know if you have comments on the presentation or my talk!

Slides are also posted on SlideShare.

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.

OSCON presentation: Managing Community Open Source Brands

I recently presented a session in the Business track this year at OSCON 2012 about Managing Community Open Source Brands. My slides are posted here.

Looking back on the slides now, I’m finding that my original CFP submission did a far better job than I hoped at the time at covering the key points I’ll have time to cover. The hardest thing about writing this talk has been scaling it down to fit – there are far more issues about efficient project governance, basic trademark law concepts, and potential enforcement strategies than could possibly fit in a single session.

Hmmm. Maybe I’ll improve on this next year so I have an excuse to come to OSCON 2013…

Thanks to all who attended – the talk went very nicely, and I’m looking forward to some feedback. Brand management for community-led projects is a conversation that we’re just really starting – one that is an obvious follow-on to the licensing models and community strategies that folks at places like OSCON have been perfecting in the past decade.

Meritocracy and Hierarchy at Apache

Apache is actually governed in two ways: by the meritocracy of the Apache Way, and the hierarchy of the Apache Software Foundation. We strive to govern ourselves as much by meritocracy (and consensus) as possible, and as little by hierarchy as is practical for non-profit corporation. This has a number of both practical effects, as well as a number of social corollaries.

The ASF prides itself in running as a community-based meritocracy of peers. That is, within each project community, people participate as individuals and gain merit as measured by that community. The community recognizes your merit by voting people in as committers or PMC members. A new committer can vote on certain kinds of code changes, and can checkin their own code. PMC members vote on new committers and product releases.

In Apache projects the underlying cliché is correct: those who are doing the work get to make the decisions. A healthy community will seek consensus over the direction of the project, and typically only uses [VOTE]s to solve thorny technical issues that don’t come to a clear consensus. Similarly, PMC members each have one vote on elections for new committers or PMC members; decisions within projects are made by the community as a whole. Technical governance is always done by meritocracy.

Even within the Foundation – i.e. the Delaware registered non-profit corporation that makes the ASF a legal entity – we strive to govern by meritocracy as well. Nominating new members and electing the board of directors are the obvious rights of members, and these are discussed and judged based on individuals’ merit towards the various Apache projects and to the ASF as a whole.

Similarly while the board appoints individuals to serve as corporate officers with specific delegated powers, all Apache members are allowed to subscribe to any mailing lists and participate across various ASF activities. Various members step up to work on policy, corporate, legal, treasury, and many other tasks that are needed in any corporation, always working with the relevant officers. Again, those who do the work decide how it gets done.

In these organizational tasks, it’s not always as clear how to reach consensus on contentious issues. Social issues or corporate governance questions don’t often have as simple a metric to measure against as technical issues do. Code either works or it doesn’t; corporate policy often has a very different kind of judgement. Similarly, with an active membership (with many very passionate individuals!), finding consensus on non-technical questions amongst 100+ individuals is often difficult. Here, hierarchy steps in to govern.

In most cases this works smoothly. Either the relevant officer will make a policy decision and publish it, or the board will pass a resolution or clearly ask for a change. While the whole community – the membership, the various PMCs of Apache projects – may not have a consensus on the decision, it is still policy, and projects will generally work to make the change.

In some cases, this doesn’t. A key way that the board ensures there is sufficient oversight of all Apache projects is by requiring reporting: monthly for officers; quarterly for PMCs / projects. There have been cases where PMCs have not reported regularly, or have not provided sufficient details to the board’s satisfaction in their reports. In these cases, the board will require a new or updated report. This is not a question of merit, or getting a consensus: this is an order. Non-response to a board request or not following an officer’s policy will and does result in the board stepping in to force changes within the project. As they say in politics, officers serve at the pleasure of the board.

It seems that sometimes this switch from meritocracy – where everyone in the PMC has an equal say, and they reach consensus – to hierarchy – where the board says “jump” – sometimes catches people by surprise. Sometimes, it seems that some PMC members just never really thought about the fact that the ASF is a legal corporation, and must follow certain rules. Other times, this surprise is clearly exacerbated by poor communication in specific cases between the board and projects. While cases like this really aren’t a choice – the board can and will dissolve or reconstitute projects (always as a last resort!) – it is important to clearly explain the issues and why this kind of hierarchy is needed in some cases.

Has anyone else had this feeling? Of switching between meritocracy, and consensus among the community, to hierarchy, and the board simply making a decision? How can we improve the handling of future issues like this, to ensure we keep the maximum meritocratic freedom within our projects, while still ensuring the legal shield of the ASF is secure and can function for the long term?

I’ve been thinking about this lately since I recently drew up a new org chart here for the ASF as a whole. Note that the hierarchy part only comes in on organizational, legal, and similar matters – technical decisions are always in the meritocratic hands of the PMCs and projects. More reading can be found on some of these excellent slides about Apache and open source.

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.