A "One Legged Man in an Ass-kicking Contest"

This is my favorite quote from a Reuters story *ever*. Some 77-year old Floridian talks of how he was scrambled to shoot down some massive unidentified aircraft the “size of an aircraft carrier”. Here’s the money quote from this Reuter’s article:

In a written account, Torres described how he scrambled his F-86 D Sabre jet in calm weather from the Royal Air Force base at Manston, Kent in May 1957.

“I was only a lieutenant and very much aware of the gravity of the situation. I felt very much like a one-legged man in an ass-kicking contest,” he said.

“The order came to fire a salvo of rockets at the UFO. The authentication was valid and I selected 24 rockets.

This is a quote worthy of Patton.

They Should Have Named it "Earth Bang"

A new magazine from SciAm has the title “Earth 3.0″…

The article that introduces the name and talks about the meaning of “Earth 3.0” follows many of the patterns of introducing a new X.0 modifier. Those patterns as defined in my post on O’Reilly News are:

  • Appeal to anonymous general sentiment that a “new” movement is building.
  • Speak of the new movement as one that is emerging.
  • Introduce the movement as a realization of egalitarian ideals.

When a new “3.0” name is coined, there is a fourth pattern which emerges… the need define the previous two “versions” of a particular area of interest. John Rennie defines Earth 1.0 as Earth pre-industrial revolution, Earth 2.0 as Earth since the dawn of industry, and Earth 3.0 as an emerging “new way” which has both the sustainability of Earth 1.0 and the progress of Earth 2.0.

The issue with modifying something with the “3.0” name is the conceptual overhead implied. Not only does a potential reader need to recognize the implied meaning of Earth 3.0, they have to understand that you are taking the opportunity to define not only a Earth 2.0 which represents our current, industrialized approach…. you are defining an Earth 1.0 to refer to a sustainable prehistory.

The other big issue with using version numbers as a shorthand for something this important is that (as in software) a version has a limited lifespan. A term like Earth 3.0 only retains its value if you believe that we are living on or near the transition from Earth 2.0 to Earth 3.0. For the magazine and the brand to remain fresh, you’ll have to constantly remind people what Earth 3.0 is, how it is still emerging, and what still needs to be done to realize the egalitarian ideals of Earth 3.0. Any “2.0”, “3.0”, “4.0” requires a constant effort to remind people that your “dot oh” is still relevant. A few months after “Earth 3.0”, we should expect articles asking us is “Earth 3.0 is still relevant?”… the higher the number in your “dot oh” that faster the turnaround and the higher the implied overhead.

Naming issues aside, the idea for the magazine is a good one, we need a magazine that focuses on sustainability, no doubt. What troubles me here is the miscalculated attempt to coin a new moniker for the sustainability movement. You can see what they are trying to do here, they want people to start saying things like, “Now, that isn’t very Earth 3.0.” Or, “Really, we’ve got to do a better job thinking about the environment, we have to be more Earth 3.0.” It comes off sounding silly and forced.

The question that needs to be asked is, “Why the minor release version?” Why bother to keep the decimal point here? Why not just “Earth 3” How about “Earth Remixed” or “Earth 2009”? Earth 3.0 suggests an Earth 3.1. They should’ve called it “Earth times e to the t over tau”, I’d by a magazine with that title. Maybe “Earth!” (meaning the product of all values of Earth from Earth to zero, pronouced “Earth Bang”).

Proposed Moratorium on "2.0" Meme

I just published a piece on retiring the whole “2.0” meme after reading an article that tried to coin the phrase Capitalism 2.0. I’m not proposing that we abandon existing, well-established 2.0 names such as Web 2.0 (to do so on the O’Reilly site would be idiocy, no?). I’m proposing that we tell the US Meme Mint to stop printing currency for new additions to the 2.0 “memespace”.

Read it at broadcast.oreilly.com

(Did I really write the word “memespace”? I dislike this new word so much, I’m going to try to convince others to use it.)

37signals as an Indirect Competitor to Google


Note: This was originally part of the lead-in article for this Video Interview with Jason Fried. I wrote it, and then decided it was too much copy for an intro.

37signals is not Google

When you walk into 37signals’ office space just west of Chicago’s Loop, you would have no idea that you were walking into the headquarters of a tiny little company that has been the inspiration for many a startup over the past few years. There isn’t even a sign on the door announcing the office as the World Headquarters of 37signals “the company that has helped redefine the way people construct web applications (using Ruby on Rails) and conduct business (simply and without distraction)”. In reality 37signals doesn’t even have an office of its own, it sublets space from a Chicago design firm named Coudal Partners. After having visited Google in early August, I couldn’t help but draw some comparisons – where Google has invested in a massive campus encased in solar panels and the best chefs money can buy, 37signals has a sublease, a few Macs, and a modest break room. Where Google employs thousands, owns an airliner, and the combined net worth of the two founders could easily recapitalize a failing bank, you could probably assemble 37signals in a small shack and still have space for a few more.

…but they compete well (indirectly)

Even with these massive imbalances, I think that 37signals is an indirect competitor with Google in the business web application space… I think they are winning and have the advantage. Yes, I know Google could likely crush almost any competition with the resources it has, but I can’t be the only one who has noticed that Google lacks any sort of comprehesive business collaboration tool similar to Basecamp. Sure, they have GMail, Docs, Google Calendar, but there is just something about the combination of these more complex projects that doesn’t “gel”. I’ve almost never successfully used Google Calendar in a workplace environment, and while I’m constantly sharing Google Docs for my work at O’Reilly – I’m just as frequently posting thoughts to a Writeboard in Basecamp. Basecamp feels more instantaneous and personal, I can recognize relevant bits of information without wading through distractions, and if I have feedback, I send an email to the founder the company and ask him a direct question. Try that with GMail.

Ok sure, but 37signals is no still Google

Because I can just see people at the Googleplex, shaking a fist at the monitor and calling me insane, I’ll back down a bit from the comparison. 37signals isn’t “beating” Google directly, but the absence of a simpler collaboration and project management tool from Google seems like an aberration. Admittedly, Google and 37signals are not direct analogs, and I’m certainly not trying to make the case that 37signals has “defeated” Google here. While Google and 37signals both create hosted web applications that aim to replace traditional shrink wrapped software, Google certainly has a much larger business portfolio, a more global approach, and the ability to both expand into and create new markets. 37signals created a bunch of little web apps (but, again, they compete…)

So, while I don’t think there is a real shooting war here, I think 37signals has indirectly gamed Google. Google sells a series of tools to business that can be used for project management, yet many of those same business elect to buy a Basecamp subscription. If you are a company paying money ($50/seat) for Google Apps, you shouldn’t need to use Basecamp… err.. but many do? Why? Because there is something to be said for the simple, constrained, limited functionality that Basecamp provides.

Whatever, I’m a rambling madman.

Development Release of Archetype Chapter

I’m throwing together a quick chapter on the Maven Archetype plugin which was recently rennovated and rereleased with some interesting new features (like the ability to generate an artifact from an existing project). I’m starting with instructions for how to generate projects with artifacts, and I’ll eventually put some instructions for best practices for creating artifacts.

This chapter on Maven Archetypes hasn’t reached Draft status yet, it is in a pre-alpha stage. I’m publishing works in progress because I believe that transparency in writing benefits both the author and the community. A book is much more than the pages (or web pages) it is printed on, and the true meaning of a book is captured in both the content and conversation it provokes. As this is a pre-alpha release of a chapter, don’t worry about reporting typos. Expect them until a quality beta version of this chapter is released. If you do care to provide any feedback, tell me what you want to read. If, after reading this pre-alpha chapter you are longing to know how to X, Y, or Z. Go over to our Get Satisfaction page and file a suggestion or an
idea. We’re very interested in the feedback.

Don’t expect the Archetype chapter to be in pre-alpha for weeks and weeks, one thing I’m particularly disinterested in is leaving readers with cliffhanger endings – sections that provide 95% of the essential information only to leave them with a table that hasn’t been completed or a section that was written in a hurry. This is a new practice of “Agile Writing”, and I’ve taken care to publish complete sections. While the enumeration of third-party plugins isn’t complete and this chapter lacks a section on
generating artifacts, the paragraphs and third-level sections that have been published are in this version because I didn’t want to sit on the content for weeks and weeks.

Xpect ah lott of tipos inh this chapther(, but don’t report ’em yet).

Paring Down the Network

Twitter, FriendFeed, Facebook, Google Reader… it is distracting to the extreme. I recently went through everything and made sure that everyone I was following I was either: A.) Truly interested in what they had to say, or B.) a colleague of theirs. I ended up dumping about 200 follows on twitter and halving my FriendFeed subscriptions. On Google Reader, I got down to 91 subscriptions from 300, and I’m finding I’m no less informed than I was when I began the experiment…more productive because of the effort. The next question is… can I pare down my subscriptions and my follows even more?

Unfortunately, FriendFeed still likes to show me what my friend’s friends are saying, so I still find myself doing this:

Writing Books in XML

Andrew Savikas wrote about an internal discussion of XML in the book production pipeline at O’Reilly. I think he and many of the participants in that discussion miss a critical part of the discussion. Free books have a life beyond the print pipeline. Books like the Subversion Book or Maven: The Definitive Guide are developed outside of the publishers systems in DocBook format.

XML as “extra” work? Some Authors prefer it…

He writes about the “extra” work required of authors choosing to write in DocBook, in this post:

I would never argue that authors and editors should or will become fluent in XML or be expected to manually mark-up their content. I naively tried fighting that battle before, and was consistently defeated soundly. It is simply too much “extra” work that gets in the way of the writing process.

Many of the authors I’ve worked with prefer DocBook precisely because of the hassle they went through to get the Word or OpenOffice templates to work properly. Writing in DocBook is straightforward once you get your mind around XMLMind, and retreating to a “wiki-like” markup ignores the fact that much of what an author is doing has little to do with presentation and much more to do with semantics. “Manually markup content”? That sounds insane, it also ignores the fact that there is a capable tool on the market.

I’m am likely one of the only authors who has had tried to write a book in XML, Word, and a Wiki-ish markup. Even though it seems counter to reason, I always had the easiest time with DocBook. The Word templates and macros consistently blew up on me once my chapters became numerous, weighty, and highly-cross referenced. The wiki syntax was inscrutable… tell me, when you have to differentiate a code block from a screenblock from a classname… what do you do? You have to invent semantic decorations into your “simplified” wiki markup. With DocBook the process of styling and producing PDF is always very straightforward. Especially for a multi-author book, DocBook is always less work to manage once the author is comfortable with the tools.

Going back to the larger issue…

Most print books do not have online, free analogs hosted outside of the publisher’s infrastructure. A few do, let’s take Subversion and Maven: The Definitive Guide. These books have large daily traffic numbers in addition to print sales (that often rival the print sales of other non-free books). Savikas writes about what O’Reilly does “after they receive a manuscript”… To me, that’s the problem. Old-school printers could assume that, at a certain point, the book was finished and ready to be printed on a stack of dead trees. For a few books today (and many more in the future), there will be a established “pipeline” which exists outside of the print publishing pipeline.

In the short-term future, more technical content will be free by default, publishers that can adapt to external, more “continuous” publishing pipelines will succeed and publishers that hold on to the idea of a lengthy “print” production phase will fail.

Buy the New Maven Book Today (Support Free Books)

I know it seems like something of a contradiction, but if you are happily reading the free Maven book from Sonatype (and I know tens of thousands of you are), I’d urge you to buy a printed copy of the book. Even if you buy it as a gift for someone else. Here are some good reasons to purchase this Maven book:

  • Maven is a part of your everyday routine and having a printed copy would help you track down that missing option or best-practice.
  • You like the idea of a seeing a free, open book developed in a transparent manner for all to see, and you want to support that effort.
  • You are trying to convince skeptical colleagues to use Maven. Throwing down a thick O’Reilly book gives your argument more weight than the free online version.
  • O’Reilly works with printers that have a net-positive impact on the number of trees planted (more on that in a later post)

Written from a User’s Perspective

I’ve been both a Maven evangelist and Maven’s most vicious critic. I’m the first to admit that Maven is and continues to be one of the most frustratingly under-documented tools, but instead of complaining to no end about this, I’ve invested months (and months) of my own time into helping write the latest Maven Book. It is a vast improvement over both the online documentation and the previous two books: the original Developer’s Notebook from O’Reilly and the Better Builds book from Mergere. This latest book was written to be both a good introduction and a proper reference, and we’ve published what I would consider to be a good stopping point (about half way to the complete reference I would like to ultimately publish).

There has been some good support for the book so far, a number of readers have written in to tell me that they thoroughly enjoy the book and that they have found it very informative and useful given the paucity of good Maven documentation on the web. Sure, there’s a very pronounced self-selection bias in the sample of feedback, but, unlike all the other books I’ve written, the feedback from this one is overwhelmingly positive. I haven’t received a negative reaction yet (although I’m sure this blog post will trigger one).

You Decide the Fate of Free Books

If you like the idea of free, open books, I’d urge you to order a copy from Amazon. We were up to #5 on the Java list, and I’d like to enlist your help in bumping us up to #1. Maven is the most popular build framework, and if you use it and want us to continue to publish and write free books, I’d urge you to buy the book.

Earlier in this post, I mentioned that this printed version is the approximate half-way point for the larger reference I would like to see published on Maven and the associated “constellation” of tools. If you enjoy the work we’ve completed so far, buy a printed copy.