The ASF Turns Fifty

Between July 2006 and June 2007, the Apache Software Foundation (ASF) created thirteen new projects, bringing the total number of ASF software projects to just over fifty.

In June, the ASF Board of Directors promoted Jakarta Commons subproject to a top-level Apache Project. Over the past year, three other Jakarta subprojects -- Velocity, Turbine, and POI -- were promoted to top-level projects in 2006/2007. Other newly created projects include Apache Shale, Apache Tiles, Apache Santuario, Apache MINA, Apache Cayenne, Apache Felix, Apache OpenEJB, Apache OpenJPA, Apache Open for Business, and Apache Labs. Seven of the new projects were developed as part of other ASF projects, and then promoted to top-level projects, five projects are new to the foundation, and one was developed internally as a new top-level project.

Apache Velocity (velocity.apache.org) is a Java-based template engine. The Velocity Engine is a mature product, in distribution since 2001. In addition to the core Velocity Engine, the new Apache Velocity project offers five other related products. The latest addition is Velocity DocBook Framework (DBF), a framework for creating high-quality online or print documentation. DBF (velocity.apache.org/docbook) simplifies rendering DocBook files by combining Apache Ant, Java, and the Velocity Engine into a unified toolset.

Apache Turbine (turbine.apache.org) is a servlet-based web application framework. Turbine and Velocity share common roots, and like Apache Velocity, Apache Turbine is a mature product dating back to 2001. Turbine works well with both Velocity templates and JavaServer Pages, and supports a services-oriented architecture.

Apache POI (poi.apache.org) provides a set of pure Java APIs for working with Microsoft OLE 2 documents, which includes Microsoft Word and Microsoft Excel. POI is in its third major release series. In addition to Java support, POI also provides bindings for the popular Ruby language. Like Velocity and Turbine, Apache POI is another mature codebase in development since 2001.

Apache Shale and Apache Tiles are spin-offs from the Apache Struts project. Apache Shale (shale.apache.org) is a modern web application framework, fundamentally based on JavaServer Faces. The Shale codebase was originally created in 2004 by Craig McClanahan, who also founded Apache Struts.

Apache Tiles (tiles.apache.org) is a templating framework for use with web applications. Originally an Apache Struts feature, Tiles has been broadened into a standalone framework. Both Apache Struts and Apache Shale provide Tiles support as a standard option.

Formerly known as XML Security, Apache Santuario (santuario.apache.org) provides implementations of the W3C standard XML-Signature Syntax and XML Encription Syntax. Libraries are now available for use with Java or C++ applications. Before being promoted to a top-level project, Santuario was part of the Apache XML project. The original Java codebase was a commercial product, donated to the foundation in 2001.

Apache MINA (mina.apache.org) provides a unified API for transport types, byte buffers, message objects, and codecs, along with stream-based IO support and a Java Filter interface. The MINA codebase (Multipurpose Infrastructure for Network Applications) began as a merger of the Netty network application framework with a Staged Event Driven Architecture (SEDA). Today, it is a core dependency of the Apache Directory project. Apache MINA also powers point of sale terminals, multiplayer games, and other network systems.

Apache Cayenne (cayenne.apache.org) is an object relational mapping (ORM) framework for Java that combines many of the best features of Apache iBATIS and Hibernate, and then adds a sophisticated GUI modeling tool. Cayenne was first developed by ObjectStyle, LLC., and donated to the ASF in 2006. The codebase has been actively developed since 2001, and Apache Cayenne is now in its second major release series, with version 3.0 in development. An exciting feature of Apache Cayenne 3.0 will be a Java Persistence API (JPA) provider.

Apache Felix (felix.apache.org) is a community effort to implement OSGi-related technologies. OSGi technology targets embedded devices and home services gateways, but it is ideally suited for any project that is interested in principles of modularity, component-oriented, and/or service-orientation. Among other things, OSGi technologies can be used as an alternative to Java Management Extension (JMX).

Apache OpenEJB (openejb.apache.org) is a modular, configurable, and extendable EJB Container System and EJB Server. Over the last seven years, the OpenEJB group worked with two other open source hosts, Exolab and CodeHaus, before coming to the ASF in 2006. The current release of Apache OpenEJB supports the Enterprise JavaBeans 3.0 specification. The product ships with both a EJB container system and its own lightweight EJB server. Apache OpenEJB can also be embedded into Apache Tomcat to create "a no holds-barred EJB server".

Apache OpenJPA (openjpa.apache.org) is a feature-rich implementation of the persistence part of Enterprise Java Beans 3.0, also known as the Java Persistence API (JPA). OpenJPA can be used as a stand-alone POJO persistence layer, or it can be integrated into any EJB3.0 compliant container and many lightweight frameworks. The OpenJPA codebase was originally developed by BEA and later donated to the foundation in 2006. OpenJPA is already being used by ActiveMQ, BEA, Apache Camel, Apache Geronimo, Apache Ode, Apache OpenEJB, Spring, and IBM WebShere, among others.

Apache Open for Business (ofbiz.apache.org) is an enterprise automation package that includes tools for Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Software Configuration Management (SCM), Materials Resource Planning (MRP), and more. OFBiz was originally created in May 2001 and soon attracted an international base of developers, contributors, and users before joining the foundation in 2006. Today, OfBiz powers a wide variety of ecommerce sites, including 1-800-flowers.com and totes-isotoner.com.

While many ASF projects were created elsewhere, another new project, Apache Labs (labs.apache.org), is designed as a place where ASF committers can experiment with new ideas. In the Apache Labs, our committers can innovate and collaborate, without the worry of building a community first. Today's labs -- which may be tomorrow's projects -- range from new approaches to creating virtual communities to experiments in new web protocols.

The Apache Software Foundation (www.apache.org) is a not-for-profit corporation that supports the Apache community of open-source software projects. While the foundation's infrastructure is funded through a combination of sponsorships and donations, the foundation itself is composed of individual, unpaid volunteers. ASF projects are characterized by a collaborative, consensus-based development process, an open and pragmatic software license, and a desire to create high quality software.

Is Open Source a Freeforall?

Agile programming in India writes:

Most people who work on open source projects are professional programmers who use the products at work. The individuals in the Apache HTTPD group contribute to the web server because they each use the server at work. The same goes for most any open source project.

Very few open source projects let any one change the code, in the way that Wikipedia lets any one change an entry. (And even Wikipedia is locking some entries down now.) Anyone can submit a patch, but an established "committer" has to decide whether to apply the patch.

How do you get to be a committer? Easy: Act lke a committer. File tickets, submit patches, and post to the mailing list. (But most of all, submit patches!) Once the group sees that a developer knows what he or she is doing, usually, someone in the group will offer write access. But you have to prove yourself first.

As to methodology, most projects use tools like mailing lists, commit logs, issue trackers, and wikis to discuss the code and apprise everyone of every change we make. For more about open source infrastructure, see The Open Source Secret Sauce

Posted by TedHusted [Apache Way] ( April 21, 2007 11:00 AM ) Permalink

Call for Papers Opens for ApacheCon US 2007

The Call for Papers is now open for ApacheCon US, to be held November 12-16 at the Peachtree Westin, Atlanta. The conference will consist of two day of tutorials (November 12-13) and three days of regular conference sessions (November 14-16).

Please log in to the website at http://apachecon.com/html/login.html to submit your proposal. Further details about fees and are avaialable on the CFP form.

Topics appropriate for submission to this conference are manifold, and may include but are not restricted to:

The paper submission deadline is Monday, 28 April 2007, Midnight GMT.

Thanks, and we hope to hear from you, and to see you in Atlanta.

Posted by TedHusted [Apache Way] ( April 17, 2007 09:00 AM ) Permalink

Ready to Give Back? Help Sponsor ApacheCon!

Sponsorships for ApacheCon Europe 2007 are still available!

The conference opens May 1 in Amsterdam, The Netherlands, so time is short, but if your organization might be able to help, please contact Delia Frees at delia@apachecon.com or on +1 707 765 0823. Various sponsorship levels and other custom strategies are available. Our willingness to work with people does extend to convention sponsorship!

ApacheCon Europe 2007 is the official conference of the Apache Software Foundation (ASF). ApacheCon draws ASF Members, innovators, programmers, developers, vendors, and users to experience the future of Open Source development. Meet, mingle, and exchange ideas with like-minded participants on groundbreaking technologies and emerging industry trends, through informal networking, peer discussions, birds-of-a-feather sessions, and entertaining social events.

In related news, the US conference will be held in Atlanta GA, November 12-16, 2007. For Atlanta, I'm hoping to snag one of the whole-day training sessions or maybe an "Ajax Smackdown" presention, and then do that meet and mingle thing :)

Posted by TedHusted [Apache Way] ( April 13, 2007 09:00 AM ) Permalink

Getting Born Again at Apache

When individuals or communities propose a project to the ASF incubator, it's not uncommon to see reasons like "recognition" and "exposure to a wider community".

While these are common reasons, they are not particularly good reasons.

Sure, the software created by many ASF projects is widely used. But, just as many, or more, are relatively unknown. ASF membership is not a ticket to ride. You still have to do the work.

The best reason for joining the ASF is because the development community supports the foundation's mission.

Once upon a time, the NCSA web server lost its only developer. NCSA was slow to replace the developer, and the project stagnated. Many of the people using the web server needed to make changes in order to improve stability and scalability. People were posting and discussing patches on the mailing list, but there was no one available to make changes.

Finally, some of the mailing list subscribers banded together, setup their own version of the code, and started to apply their own patches. Not wanting to repeat history, the group organized itself in away that would avoid dependencies on a single developer or a single company.

Over time, the group evolved the notion of the Apache Way, which we now like to call ASF culture. We strongly believe that a codebase belongs to the individuals who create and maintain it, and that a codebase should be a collaboration between individuals. When we put these two ideas together, we come up with the term "meritocracy", to describe an organization that is run by the people who do the actual work.

The ASF culture contrasts the model of the benign dictator described in Raymond's The Cathedral and Bazaar. It is also very different that the Linux hierarchy. It's a model that says any number of people can participate in a project, so long as everyone involved is prepared to work well with others ... especially when we disagree.

In a word, our mission is collaboration.

In practice, we fulfill that mission by fostering software development communities. Everything that goes into that, the Apache License, the legal shield, the distribution policies, all speak to the fundamental mission of enabling collaboration.

As to ASF rules, after six years, I've been able to identify eleven.

It's true that working with others is often more work than going it alone. When the kids were young, my wife I would joke that the household chores take longer when the children help. But, nowadays, lo and behold, sometimes, the teens even do their own laundry!

It's hard. But, it's entirely worth it.

Posted by TedHusted [Apache Way] ( April 07, 2007 08:20 PM ) Permalink

The Geek's Glossary (ASF edition)

Recently, we were been discussing some of the definitions published in Glossary of Apache-Related Terms on one of the mailing lists. Based on those discussions, here are some changes and additions that I've been considering.

ASF - Asynchronous Software Fanatics: A cult bent on world collaboration.

ASF Board of Directors - Nerds smoozing nerds (see Community).

ApacheCon - A sausage-fest with almost enough beer.

Bikeshed argument - Discussing "what color to paint a bike shed" is why ASF committers sometimes prefer forgiveness to permission.

Build - Bits tossed into a tarball (see Release).

Commit-Then-Review - See Review-Then-Commit.

Committer - A geek with way too much spare time.

Community - Geeks goosing geeks (see ASF Board).

Darwin - The two-faced icon of Evolution and Revolution.

Dog Food - We ate it, now it's your turn.

Emeritus - A committer with a life.

Evolution - Darwin meets the tyranny of the installed base.

Freeloader - Someone who downloads and uses open source products but never contributes back by reporting an issue, submitting a patch, testing a beta, or helping another user on the mailing list. Even once.

Hat - Sybil meets Minnie Pearl (see photo: "Minnie wearing her PMC hat").

Incubation - A process designed to frustrate projects into submission.

Irony - See Karma.

Joy - That rare feeling when software actually works!

Karma - By doing more, we let you do more, by granting you karma to do more. See Merit.

Lazy consensus - The best kind.

Merit - Working more, jabbering less, lurking not.

Podling - We are Borg. You are borgling.

PMC Chair - Every project needs a tattletell.

Project Management Committee (PMC) - War is peace. Freedom is slavery. Projects are managed.

Release - A tarball that stuck to the wall (see Build).

Review-Then-Commit - See Commit-Then-Review.

Status File - A hit-and-miss project journal that, when kept, can only be found in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Mentor'.

Subversion - Never having to mean you're sorry.

Revolution - Stick a fork in it and see who bites.

Veto - Severe change reduction.

+1 - A negative veto.

PS: Be sure to enjoy this special day!

(Apologies to Ambrose Bierce)

ASF Rules Redux

People often mention "Apache Rules". We don't actually have a rule book, but if we did, here's what I believe might be the top eleven practices.

Of course, there are other customs of Apache culture, but I believe that most other ASF practices would stem from this initial set. And, as with all things ASF, YMMV! :)

13 ASF Practices

People often mention "Apache Rules". We don't actually have a rule book, but if we did, here's what I believe might be the top thirteen practices.

Of course, there are other customs, but I believe that most other ASF practices would stem from this initial set. And, as with all things ASF, YMMV! :)

Why do we call it Apache?

Digging into the email archives we find ....

As with many things, there seem to be two reasons. Because it sounds like "a patchy" and as a tribute to the native Apache tribes.

I'm surprised no one mentioned the helicopter! :)

Who let the dogs out?

There are open source teams that configure themselves much like a conventional closed-source team. The team has a clear hierarchy where someone has the final say, the team's goal is to create software to benefit "users" and other "stakeholders", and the team's underlying objective is to acquire as many users and stakeholders as possible. Users are somebody else.

The founding principle of an ASF team is that we too are the users. We create the software for our own use and benefit, and then we share the result with other users.

We eat our own dog food, and we pass the bowl.

Our participation in the team stems from our own external use of the team's product. We use the product in our own day jobs, and we cordially invite others to do the same. The interest of team members will vary, depending on how things are going on the day job. Accordingly, we need a steady infux of new contributors. Attracting new users is our way of recruiting new contributors.

When an open source team is not comprised of users, and the object of the exercise is to create software for other people to use, dynamics like "competition" and "jingoism" do come into play for those teams, just like they do for conventional closed-source teams. But, at the foundation, we are not trying to mimic conventional teams.

An ASF community is not the set of all users and other stakeholders. An ASF community is the set of active participants who make concrete contributions to the code, documentation, and project infrastructure.

We aren't selling fish; we're creating fishing holes.

Posted by TedHusted [Apache Way] ( May 21, 2006 10:30 AM ) Permalink

How do you spell Community?

Some projects use the word community to be synonmyous with "stakeholders". For example, Spring addresses its product announcements to "The Spring Community". Evidentally, the committers are not the community, since they would not need to address these announcements to themselves! From this perspective, the "community" is somebody else.

Other projects use the word community differently. At the ASF, we sometimes talk of a project "losing its community". When we say that, we do not mean the software isn't being used. We do not mean that the software has no stakeholders. We mean that there is no one that is actively contributing to the software. No one is applying patches. No one is answering posts to the mailing lists.

In fact, the Apache HTTPD product was born because the NCSA server "lost its community". The server's primary developer, Rob McCool, left the NCSA in mid-1994, and the project stalled. People were still using the server, and users were circulating patches to correct this bug or add that feature. But, no one was creating a distribution that incorporated all the latest patches. In response, a small group of volunteers banded together to create the Apache HTTPD community, and the rest is history.

People being people, we are not always consistent. Sometimes when ASF folk say community, we mean the set of stakeholders. Sometimes, when we say community, we mean the core group of contributors that apply the patches and answer posts to the mailing list.

But regardless of how we use or misuse the word community, in the end, ASF committers still eat our own dog food. In the end, we are all trying to build the product that we want to use ourselves, in our own day jobs. Then we share the wealth, just in case other people might want to use the product too.

Posted by TedHusted [Apache Way] ( May 14, 2006 10:30 AM ) Permalink

The Truth with Jokes

Q: Are ASF committers arrogant?

A: Yes, we are.

Q: Is the ASF a club?

A: The ASF is a non-profit corporation, but, yes, it's organized like a club. We have meetings, and minutes, and a board of directors. Just like your kid's soccer club!

Q: Is the ASF exclusive?

A: Yes, it is. We exclude committership to "people that we believe are devoted to the task and match the human attitudes required to work well with others, especially in disagreement". Even so, most projects manage to attract ten or twenty active committers. Very large projects, like Jakarta, have hundreds of committers. Of course, not all of these committers are arrogant. Some are merely smug.

Q: Why not lower the bar to commit rights? Why not hand out write access to anyone who asks?

A: It's simpler for us to expect people to first submit patches. (And, of course, it's all about us!) Just to play hard to get, we usually string people along this way for at least six months before offering commit access. Mainly, this is because creating accounts is a bother.

Q: Why not change the system?

A: The system works for us, where "us" is defined as thirty top-level ASF projects with almost two thousand ASF committers. Some projects, like Cocoon and Struts, were created here. Others, like iBATIS, Lucene, MyFaces, and Tapestry, began elsewhere and then joined the ASF. Some projects, like Ant and Tomcat, were created elsewhere and then reinvented here. Evidentally, arrogance loves company!

Q: Don't the people who download and use your products have rights too?

A: Yes. Users have all those rights conveyed to them by the business-friendly Apache License. We like to say "business-friendly" in a smug way, because some other licenses are just plain mean.

Q: But aren't you creating software for use by the general public? Doesn't that give the general public a stake in the project?

A: The software is created and maintained by the development community for its own use, and then, just to neighborly, we share the product with the general public, at no charge. We do accepts tips, but only in the form of a patch.

Q: Shouldn't open source be more open than that?

A: Our goal is to (deep breath) ... foster an environment where people are able to collaborate on software development in a respectful, honest, technical-based way in order to create consistently high quality software that faithfully implements standards, while retaining security as a mandatory feature. (Whew!) After over a decade of experience working in open source, we believe the ASF process is the best way to nurture that environment. We also find it's the best way to retain the trademark ASF arrogance.

Q: Can other projects join the ASF?

A: Yes, but they have to bend over, grab their ankles, and exclaim "Thank you Incubator! May we please have another?" while ripping out any dependency with an unsavory license. A podling can only embrace what it means to be an ASF project by stumbling through a haze of pain.

(OK, here's the joke:)

Q: How many ASF committers does it take to change a lightbulb?

A: Three. One to hold the bulb and two to turn the ladder while chanting "+1".

PS: Be sure to enjoy this special day!

Posted by TedHusted [Apache Way] ( April 01, 2006 06:41 AM ) Permalink Comments [2]