The Apache Software Foundation (ASF) celebrates its tenth birthday today. On March 25 in 1999 Roy Fielding signed the foundation's incorporation papers. Happy birthday!

A lot of successful and industry-changing software has been developed within the ASF in the last 10 years: see here for some of the ASF's highlights and the very well written "How the ASF works" page.

Day has strong relations with the ASF: we heavily contribute to and base our products upon the projects Jackrabbit and Sling. Moreover, many of Day's employees are involved in other Apache projects or serve in other ASF functions (see here for more information about Day's open source activities).

Therefore, I was more than happy to take this opportunity for an interview with Roy Fielding and Bertrand Delacretaz where they share some of their insights about the ASF's past and future. Day's Chief Scientist Roy is co-founder of the ASF and its former chairman. Roy also wrote the Apache License 2.0. Currently, he is V.P. for the Apache http server project. Bertrand (Senior Software Developer at Day) is a member of the Apache Software Foundation and an active committer on the Sling and Tika projects. He is also committer but currently inactive on the Cocoon, FOP, and Solr projects. Bertrand is also on the ASF's board of directors.

Roy Fielding

Founding the Apache Software Fondation was extraordinary for an open source project at that time (in 1999). The history pages of the ASF describe the reasons for founding the ASF as a kind of defensive act to protect individuals against legal threats. Was this the only reason or were there other ideas involved?

There were several reasons for incorporating. Although the Apache Group had been successful operating as a group of individuals, it was becoming increasingly difficult to deal with the outside world without a formal legal entity. We wanted to protect the Apache brand name against abuse by other organizations. People wanted to donate money to the project, but we had no way to accept it other than as individual income. Some of us wanted to organize a conference, which later became ApacheCon '98, but the liability issues required that it be produced by one of the companies that employed some of our volunteers. Most of all, it was the fact that we couldn't make non-technical decisions quickly: we actually started to discuss incorporation in September 1996, two and a half years before I signed those final papers.

The final straw came in 1998, when folks at IBM contacted the Apache Group in private to investigate contributing as part of the team of developers (IBM's first exposure to open source development). Before we could talk, however, IBM demanded that each of us sign a non-disclosure agreement, which is standard practice for any large public company. It would have been easy to do so if we were a legal entity, but instead we had to obtain written signatures from every single person in the core group, located all over the world.

An aspect that sets the ASF apart from many open source efforts is the invention of "incubation of projects" and, even more revolutionary, the "retirement of projects". What was the background of coming up with these concepts? Were there concrete projects that triggered this idea?

The Apache way of developing software is ideal for collaborations among developers regardless of their individual employers. Once we had incorporated and formalized the licensing agreements, the ASF grew very quickly as new projects were proposed. At first, the board created projects that covered entire areas, such as Java (later renamed Apache Jakarta), XML, and Perl. The Jakarta project, in particular, attracted hundreds of developers that wanted to contribute their own libraries and applications to Apache, and so each project started to act like the board and created sub-projects of their own.

However, there is more to the Apache way of development than just starting a project and letting the developers run wild. We have learned over the years that each team must be organized for peer review and formally vote on all releases, which requires some cultural learning on the part of new developers. Likewise, we need to ensure that we have sufficient legal paperwork for any software that is licensed to the foundation for further development, since copyright laws are applicable for seventy years (or more), far beyond the normal memory of any project. The early projects grew so fast, however, that it was impossible for the experienced Apache developers to keep track of the growth and mentor new volunteers.

The Incubator was the board's way of adjusting the organization to that rapid growth: by forcing all new projects to learn about the Apache way of development and actively engage ASF members as new project mentors, we found a way to grow the organization at the same rate that we were growing projects and volunteers. Of course, there are also many negatives to that approach: it can often seem to new projects that Apache is dominated by bureaucracy and process, since much of that process is only needed when conflicts emerge.

You wrote the Apache License 2.0. One key feature of the license is its commercial friendliness. Was that an explicit design decision of yours or is it a by-product of other design considerations you had in mind?

Apache has always used a commercial-friendly license, since we were founded by a diverse group of individuals from both academia and industry. Many of us had prior experience with the BSD license, which does not place restrictions on other software distributed with the product. Furthermore, since one of our original goals was to enable standards-based interoperability on the Web, we encouraged the other software-producing organizations to use our code instead of their own (often buggy and nonstandard) implementations.

This openness to collaboration among developers, no matter why they are interested in participating, is one of the key virtues that make Apache projects both fun and educational. Our licensing goal was to ensure that the final work product would be usable and redistributable by anyone, for any purpose, but without any warrantee. That is why we used a variant of the BSD license for the first five years.

The 2.0 license came about as an attempt to clarify both what the license grants under copyright law and what the contributors had agreed to grant under both copyright and patent laws. We wanted to protect ourselves and our users against deliberate contribution of works under "submarine patents" or other license that were more restrictive than our own. We also wanted to enable compatibility with GPL-based free software by providing an innovative way to acknowledge the original developers (if they so desired) without exceeding the restrictions in the GPL.

Ultimately, we measure the success of our license by how many organizations and individuals can safely redistribute our software without entangling the Apache developers in lawsuits. So far, we've been 100% successful.

Looking back at the ASF's history: what surprises you the most? What did you least expect to happen?

I think what has been most surprising is the ability of Apache projects to persist and evolve as the individual volunteers change their interests and move on to other things. In every way, Apache is entirely dependent on the imagination and effort of individuals. We are often working on problems that are only indirectly perceived by everyone else, and each is only working on Apache part-time.

We've had at least six different technical leaders within the HTTP server project over the past fourteen years, each of whom led the group in implementing massive improvements to the software in relatively short periods of time and then moved on to other problems within or outside the ASF. We have designed an organization that is able to make use of the vast numbers of volunteers on the Internet, and yet remain cohesive enough to retain its unique project culture and freedom to innovate.

I think what I least expected to happen is that I would still be involved in the project after all these years. I have been less involved in the code than I was in the past, but I still managed to fix a few issues this year and look forward to trying out a massive redesign in the coming year.

Over the years I've stretched into the various roles of just being one of the hackers to becoming the standards cop, from resolving technical conflicts into codifying the voting rules, from people management into project historian, and from release manager into semi-retirement status (only to come back again). To incorporate the ASF, I had to become familiar with corporate law and learn to communicate with corporate lawyers, create bylaws and a board to enforce them, learn how to be a Chairman, and teach a bunch of techies how to use the organization to make non-technical decisions in a business-like manner, preferably without turning the foundation into another work environment. The 2.0 licensing work required an understanding of copyright and patent law, starting Apache Jackrabbit meant learning how to be a mentor for contributors (and co-workers) new to Apache, and becoming chair of my old HTTP server project has been a challenge to motivate the revival of a project that had become complacent and overburdened by its own success. I am proud of each of those roles, though there is plenty of work still left to do.

Staying involved in Apache has proven to be the most consistent educational experience of my career -- I learn something new every week, especially when new volunteers enter the project and add their own perspectives and experience.

ASF's software has been integrated in endless commercial offerings. How should interested companies give back to the ASF? Day's approach of paying wages for open source developers is only one way. Straight payments, sponsoring events, but also opening patents or evangelizing the open source idea come to my mind. What is your thoughts on this?

First, I always encourage companies in our industry to hire the developers on Apache projects. How could they possibly go wrong in hiring a person who develops software for fun and has already proven their ability to produce peer-reviewed quality software as part of a self-selecting and meritocratic team?

However, there are many other ways to directly contribute to the Apache Software Foundation that are explained on the ASF website. The ASF is a nonprofit US corporation (IRS 501(c)(3) charity), so individual donations are often tax-deductible. In addition, we have a corporate sponsorship program that contributes the bulk of funds needed to run our Internet infrastructure and the other non-sexy parts of running a major foundation.

In terms of evangelizing open source, I actually encourage folks to do that within other organizations, such as OSI or the EFF, rather than at Apache. I think what Apache does best is to lead by example rather than by publicity or marketing. We do that by producing collaborative software development projects in a safe and consistent fashion, by producing software that is better than any single person or company could produce on its own, and to do all that while having fun.

Bertrand Delacretaz

Thanks for your questions. Please let me note that the answers below are my personal opinion, and do not necessarily represent an "official" position of the ASF. Nobody voted +1 on those yet ;-)

Bertrand, like most of Day's engineers you are a long time Apache committer. Currently, you are most active in the Apache Sling project. What would you say in how far the "Apache way" of software development influences development within Day in terms of process and product.

The Apache Way is very present in our development team's way of working, at Day. We use similar collaboration tools internally as in our Apache projects (source code control, issue trackers, mailing lists, wikis, continuous integration, etc.), decision-making principles are similar (including the "+1 / +0 / -1" way of voting), and in general all the necessary project information is available in self service mode for our developers. No need to run around the office to find out who wrote a particular piece of code or why it is needed - all this info is available in the "central knowledge base" that these collaboration tools manage without much intervention on our part. Among other benefits, this allows us to work efficiently from anywhere and at any time. We can also make much better use of face-to-face meetings, when they happen, without needing to first exchange that basic day-to-day information which is flowing automatically all the time.

You are one of the nine members of the board of directors and that job probably gets you to look at many aspects of Apache projects. What are the common struggles for projects and what are the upcoming challenges for the ASF as a whole?

I would say that, as a general rule, the ASF's projects have many more successes than struggles. Most of our projects are doing very good, thanks to a very good understanding, among developers and users, of what it takes for their communities to thrive. The overall well-being of our projects has improved in the last few years,in my opinion, thanks to developers getting more familiar with the open source way of working. That's remarkable, considering people who collaborate in our projects often come from different cultural backgrounds, speak different languages and usually meet only rarely, if ever. That would usually be a recipe for failures, but our communities work very well!

There are challenges related to our growth, and to the fact that the foundation has grown into a federation of projects that don't always know each other very well. It is the members and the board's duty to make sure our values are actively promoted in all of the ASF's projects, and until now that works quite well. But staying true to our values despite with the kind of growth that we're experiencing does require constant vigilance and regular adjustments to the way we communicate and share those values.

The ASF has grown from 200 committers to about 2000 (acording to the Wednesday's State of the Feather at ApacheCon). Do you expect this trend of rather strong growth to continue? What would you consider the limits of organizational scalability of the foundation - if there are any?

The trend will certainly continue, and the federated way in which the ASF is structured makes it possible to grow to larger numbers. The board of directors currently reviews about 20-30 project reports every month, to keep the oversight, and that works as we do trust our projects, try not to interfere with them unless really needed, and ask them for reports on specific topics (mostly community and development events, and issues that might require board attention). The members of the foundation (about 300 of them) do a very good job in keeping an eye on things at all levels and raising alarms when needed, which is not very often.

We are making some minor organizational changes, like hiring outside help for administrative tasks, to cope with this growth, but from a structural point of view the ASF is ready to grow more. As long as we have enough active members that we can trust, and sustainable mechanisms to allow the board of directors to keep the oversight as we have now, we should be fine.

There are some Apache projects that collaborate with Google's summer of code program. Do further plans exist within the ASF to assist in the education of the young about open source development?

We don't have specific plans, as far as I know, but the people who lead the Summer of Code effort in the ASF are members of the Press Relations Committee, who is also tasked with outreach in general. I have talked to many of our members and committers who are willing to help youngsters get on board and understand our way of working, so we can probably expect more activity in this area in the future.

Projecting your views of the ASF into the future, say, 5-10 years: what do you think will change, what will stay the same?

The ASF projects are mostly about web infrastructure, and I don't see that changing soon. Like developers in the last few years, I think more companies will learn how to collaborate efficiently with the ASF, while respecting our basic principles, and that will help them and us work together in a sustainable way in the long term.

The Apache Way is here to stay, even though tools will evolve; distributed source code control is probably the next important thing that will happen in our toolset, and although that will change some aspects of how we work, I don't expect a revolution.

It is impossible to say exactly how the ASF will look in ten years, but I'm quite convinced that we will stay true to our basic principles, and continue to be a successful neutral ground for people and companies to collaborate on creating great software, often with a global impact.

All this looks like a bright future, and the amount of dedication that I see in so many volunteers involved in the ASF gives me every reason to be optimistic about it.