The Truth with Jokes

Essay

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!

Action2 Cookbook Sizzles

Review

So far, there’s been only one thing I missed while setting up a new
Struts Cookbook for Action 2. An essential part of the Cookbook is displaying the source files used to code the example. In the Stuts Action 1.3 version, we were using the Bean tags to dynamically read the file into a page variable and then output it with the tags filtered. The Struts Bean tag idiom is:

I couldn’t find an obvious way to do this with the WebWork tags and started a thread on the WebWork user list. After a post or two, we hit on the idea of using a WebWork result to display source code as plaintext. Before I had the chance to write it myself (in the Apache Way), WebWork committer Toby Jee posted a new PlainText result to the HEAD, which I happily plugged into my work in progress.

The WebWork idiom moves all the references from the pages into the configuration file. The simplest example is a one-page “Hello World” recipe. The mapping for the PlainText result looks like this:

  
/pages/Hello/Result.jsp
/WEB-INF/classes/xwork-Hello.xml

In the page, the links are coded like this:

Server Pages

  • Result.jsp
    The cool part, is that through use of namespaces, each example can have its own “View=Result” action. We need to refer to the namespace on on the Home page, but after that all the tags render themselves relative to the namespace. Here’s are the the home page links (one for the icon and another for the text):
 namespace="/Hello" 
Execute

But once we link into the “/Hello” namespace, the ww tags take care of injecting the rest of the path.

Of course, any post-Struts-1.1 developer is going to be saying, “Oh, namespaces are modules!”, and you’d be right. Everything in WebWork is very much the same as Struts 1.x. Only better!

If you reviewed the previous code snippet, you probably noticed the reference to “icon-open,jsp”. The Cookbook uses icons for navigation, which I removed to their own server pages and then brought back in using ww:include as needed. As a result, all the image markup is centralized and not scattered throughout the application.

The new Cookbook also uses ww:include to post navigational header at the top of the pages. The nifty part is that the WW tags track the current namespaces. If we consistently name the entry action to each example “Open”, we can reuse the same menu link for every example/namespace. When the Hello namespace includes this snippet –

– the action location renders as “/Hello/Open.do”. When the Simple namespace renders the same snippet, the location renders “/Simple/Open.do”. Quick, easy, effective.

I’ll be heads-down on the Cookbook this week, and will surely post more about the Cookbook again next week. In the meantime, you can track the progress in the Apache Struts sandbox, and I’ll try to keep the online demo fairly current.

Action2 Cookbook is off the backburner

Review

I finally got a start a merging the Struts Action and WebWork 2.2 example applications. For Action 2, we might end up with something like

  • Blank
  • Cookbook or Showcase
  • Portlet
  • MailReader

  • ShoppingCart
    I checked in preliminary alpha versions of the Blank2 and Cookbook2 to the Apache Struts sandbox yesterday. Ultimately, the Cookbook would incorporate the use cases in the WebWork ShowCase, the original Struts Examples, along with the new Struts Cookbook.

  • Showcase

  • Examples

  • Cookbook
    Once a working version of the Action2 Cookbook is up and running, a WebWork MailReader would be next. While building a new MailReader, I’d be sure to add generic versions of the use cases to the new Action2 Cookbook.

  • MailReader

Planet Struts Countdown

Event

In keeping with the “Embarrassment of Riches” theme, I’m pleased to announce the Planet Struts blog site. Planet Struts aggegates announcements about Struts and Struts-related products, along with Committer blogs. To prime the pump, we back loaded a few months’ worth of announcements.

  • http://www.PlanetStruts.org/roller/
    Meanwhile, there were three Struts Resource directories in existance, but none of these were complete or up to date. With Shale and WebWork/Action 2 in play, it seemed like time for a new directory that covered all the Struts products, and also strove to be comprehensive. Enter Struts Central:

  • “http://www.StrutsCentral.net/
    Struts Central is designed to complement Planet Struts. New resources can be announced on Planet Struts and the link summarized and archived on Struts Central.

The official launch date for these sites is March 1, but I thought my blog-watchers deserved a sneak-peak. Enjoy!