My new mantra is "Email is not work".  I just got back from OSBC 2008, and saw once again, how tied we all are to our electronic devices.  Now I like my BlackBerry as much as the next person, but I'm afraid that we may be so busy checking email that we are missing out on valuable opportunities to think and learn.  Matt Asay talks about this in his blog Back in the good old days when I had time to think. 

I only got my BlackBerry about 6 months ago.  My impetus for buying it was a bike trip to Italy last October, where I needed to have some ability to communicate with work.  I didn't want to be forced to spend time tracking down internet cafes when I would rather be on my bike or exploring a Tuscan hill town with my friends.  My fear in getting the BlackBerry was that I would become one of those "crackberry addicts".  As a recovering workaholic, I've (finally) learned to create some boundaries around my work.  It took a cancer diagnosis a couple years ago to make me realize that, as much as I love my work, spending all my time consumed by work was not the way I wanted to spend my life.  I also know that time I spend thinking is way more valuable to my company than time I spend checking email.  Hence my new mantra.

This has been my second year of attending the OSBC conference, and each year I've come back from the conference with new insights and "aha's".  I've been able to learn about how other companies have been successful and think about how OpenLogic needs to evolve as we grow our business.  I'm pretty positive those insights are way more important than an instant response to an email.  I will continue to use my BlackBerry to help me in my work, but I choose not to become addicted. 

 In his summary What I learned from OSBC 2008, Matt Asay commented on how we align open source business models with customer satisfaction (and willingness to pay".   According to Matt:

Enterprises love open source but the business models necessary to fuel both their happiness and that of the vendors still need a lot of work.

Jon Williams of Kaplan Test suggested in his keynote, as Dirk Hohndel captures, that the more happy he is with his commercial open-source software, the less likely he will be to pay for it. Why? Because his developers will acquire the expertise over time to support themselves and because the product will mature to the point that support will be less necessary.

The vendor can respond in two ways: Innovation and proprietization (made up word). By innovation, Jon suggested that continual development of the product keeps it buggy (my word, not his) and out in front of his developers, such that support remains relevant. Vendors can also offer services like the JBoss Operations Network that make maintenance of the software easier.

A combination of both is optimal, but Dirk is right that it's a bit depressing, this prospect of the customer leaving just when you've made them the happiest. 

 I've been thinking about this topic a lot, and especially how we can provide value around support. 

Like many people in the open source world, I spent many years working for proprietary enterprise software companies — mostly startups but also a few large companies like Hyperion and PeopleSoft.  During my time at the larger proprietary software companies, I saw how support teams were very eager to point fingers at other vendors and play the "blame game".  If they could feasibly point at the database or the operating system or the custom code written by the customer, they were very happy to declare it "not our problem".  Part of the reason for this approach was that the support teams didn't really have enough expertise in all of the components and infrastructure that worked around their own product and didn't want to spend the time and effort needed to troubleshoot a problem that could end up being in "someone else's code".

In the open source world, the support problem gets more challenging.  In the area where OpenLogic plays (above the operating system and below the business applications), companies are typically combining many open source packages, custom code and proprietary solutions to create their critical business applications.  Yet in these large companies, the expertise for each of these components is highly distributed.  There's an app server team, a database team, an infrastructure team, a network team (you get the picture) and often there's no one at the company that has the complete picture of how all of the components work together or, more importantly, why they are not working properly. 

At OpenLogic, We find that our engineers providing support need to have superior troubleshooting skills in order to follow the problems through the whole system to find the root cause.  That also means being willing and able to cross boundaries between products (even when they were not bundled by the vendor) to solve the customer problem – wherever it lies.  In fact, we rarely find that the problem is a bug in the open source package.  Most often we find that is some configuration or integration issue, or a problem with how all of the pieces interoperate.  When we solve these types of issues for customers, they are thrilled, ecstatic and grateful.  They are happy that someone is helping solve their business problem – regardless of its source. 

This wasn't something we fully appreciated two years ago when we first launched our support offering, but I think this lesson is an important one for all open source companies.  Just as open source has brought new, more transparent ways to engage with customers around product development, open source also brings new ways to engage with customers around support.  By breaking through narrow product silos, we can increase our value to customers and fuel customer happiness with open source companies and the services they provide.

Earlier this week Jimmy Guterman blogged about his decision to cancel his subscription to the print edition of The New York Times. He still loves the paper, both from a content standpoint as well as “the serendipity of walking through a print section”, but one day he came to the realization he was reading more of the Times online. “For all the pleasure of holding and print, the Times on paper is just too late. In 2008, today's paper is yesterday's news.” He goes on to lament the fact that the print version probably can’t survive if he and other adoring readers cancel their subscriptions, but that isn’t enough to change his mind.

I can sympathize with Jimmy’s point—I’m a news junkie and a big fan of the printed word—but a few years back I too realized that I was reading most of my news online while the print newspaper went straight to the recycling bin. However, while environmental concerns and the practicality of online news contributed to my decision to stop subscribing to the local paper, I have to admit that my primary motivation was an ever-increasing level of annoyance with the teenage subscription-sales reps that the Denver Newspaper Agency continually sends door-to-door through my neighborhood. Especially in the warmer months, you can find these kids trolling through the neighborhood at least once a week, and they’ll knock on your door whether or not you’re already a subscriber. Even more annoying is the fact that the Denver Newspaper Agency promises to award small “scholarships” to the kids that sell enough subscriptions, so they always deliver emotional pleas about how my subscription could help them get through college. I like to point out that it’s not a scholarship unless it’s awarded for scholastic merit or financial need and that they’d be better off getting a regular job, but the message doesn’t seem to resonate.

I eventually hung a No Soliciting sign near the front door in response to their repeated visits, but it’s had little to no effect. I don't know if they can’t read or don’t care, but either way I’m not going to reward them with my business. I’ll continue to read the local papers as well as the Times and other news sources online, but at this point I don’t really care if print newspapers go the way of the dinosaur.

Radiohead was one of the first bands to release an album for free over the internet, but they later wound up releasing a regular album and taking their download links down. They also view the effort as something of a failure, and Trent Reznor chalks this up to them being insincere. Reznor points out that the album was poor quality and not released under Creative Commons.

What we have here is a band that dabbled in these kinds of open source concepts, and wound up failing as a result. We also have a band that jumped into the philosophy whole-hog, releasing the album for free in high quality and under a copyleft license, which wound up being extremely successful.

We see this happen quite frequently in the open source world. Sometimes companies will start open projects but still exert a great deal of control over them, preventing outsiders from becoming committers or otherwise stifling the community. Projects that start this way often fail, and they are largely rejected by the community from which they are seeking support. It's no surprise that these album releases, given the open-source-style nature of them, follow a pattern that is often observed in the open source world. Embracing the concepts entirely winds up being better in the long run. Doing it insincerely results in failure.

REM has recently released a new album for free on the internet as well, but in a format even more crippled than the Radiohead release. This album is only available for streaming (not download) in low quality, for a limited time, and only on a specific proprietary web site. If the failure/success of these albums depends on some part on how sincerely they embrace the open philosophy, then we should expect the REM album to be a failure. Of course, only time will tell if that's actually the case.

I don't work Fridays. Unless I'm traveling, or there are meetings or something urgent happens. But in general, I don't work Fridays.

But here's the really big secret. I do it for me. Most people assume that I don't work Fridays so that I can spend more time with the kids. Nope. One is in school and the other is in daycare five days a week. (He loves it, honest.) I don't work Fridays – for me. I run an occasional errand and I volunteer at the school a couple of times a month, but mostly I read, learn and catch up with friends.

You should try it. Not working Fridays is good for the soul.  

Jeremy Thomas posted a very cool presentation about SCRUM in his Agile Development blog post. We use SCRUM to develop products here at OpenLogic and I don't think that I'll ever use another development methodology. I've worked in waterfall, spiral, and rapid iteration environments, but nothing compares to the ease and efficacy of SCRUM.

As product manager, it's my job to make sure that the efforts of our hard-working & brilliant engineers are channeled correctly.  This means solving the right problems, for the right people, in the right manner.  By recognizing that software development is a complex and unpredictable process, largely relying upon empirical controls, SCRUM makes my job much easier.  SCRUM avoids scope creep, the death march, the blame game, and many other ugly situations that most the software development world have come to accept as part of the job.

As I consider life after OpenLogic (shudder the thought but all good things do come to an end), I've been meaning to put together a SCRUM presentation that I could use to sell a future employer on SCRUM. Jeremy has done an admirable job. Maybe I can talk him into putting it into a portable format and distributing it under an open source license…

I was reading this blog post the other day, and it tied in to some of the recent discussion on this blog as related to NIN's open approach to making music available.  The notion put forward (and linked to) is that copy protection is pointless.  The blogger goes on to point out that "the fact that the most easily found etexts are those of the bestselling books should suffice to prove that only a very small percentage of ebook pirates were ever potential customers."

 So… this open source thing is working for much more than just enterprise software… we see it working for books, games and music.

After my “Would you do it again for free?” talk people always come up to share their stories. (It's one of my favorite parts of public speaking.) One common comment – one that initially surprised me – is “I try to keep my open source software work and my job separate.” I had assumed that everyone's “dream job” would be getting a paycheck for working on their hobby. So in our recent survey of our expert community, I asked, “If there is a company associated with the project you work on, would you like to work there?” Of those that qualified, only 30% would!

We uncovered some other common myths too.

• One of the common misconceptions is that most of OpenLogic's Expert Community also works for an open source company associated with the project they support. Only 6% work for an open source company! In fact over half work for a proprietary software company. (So much for the myth that the open source community hates proprietary software!)

• Not that they don't understand the additional value that the open source software model brings. When asked if there will be a company associated with every open source software project, the response was an overwhelming no (84%) – with one respondent saying "sometimes community driven software is better”.

• And while 52% joined the OpenLogic Expert Community to make money, 64% stated that one of the major reasons they joined was to support open source software. (Don't worry – we plan to continue to pay!)

You can read or press release or check out the data for yourself below. (Note that most of the questions allowed more than one answer so they don't add up to 100%.)

Agile methodologies are much more common within the better open source projects than many would think based upon the primary tenets of Agile. Agile covets customer feedback during development of a project which is incorporated in subsequent releases or benchmarks of a project. Some might argue that open source projects lack the frequent customer feedback loops required for a true Agile approach. After all, benchmarks between open source releases are rarely seen by any end users, managers or stake holders in a company.

I would assert that the role of the customer for open source projects is the developers on the project. Most Agile projects, many of them developer libraries, succeed because a group of developers find a common need where they can collaborate to create code that each can use within some larger software project or within some larger IT system configuration. Each developer will be working on the open source project in the context of a larger project satisfying some sort of business needs. The larger project is where the end user feedback is important, more often than not, the open source project is a building block. Developers understand the building blocks; end users/customers understand less abstract, more tactile elements such as GUI's, emails, etc.

We cannot demonstrate Hibernate, Spring or JBoss to most customers or end users; these are tools that developer utilize to build or deploy applications that end users can test. A developer would provide the feedback for these open source projects and it would be rare to find a developer working on any of these projects, who is not also the consumer of the projects. In essence, the developer is the customer or end user for the open source project and will judge the usefulness of the project by its ability to save work, provide intuitive interfaces and other technical criteria.

Given that the open source developer is the customer for open source projects, then perhaps we can conclude that open source projects are truly Agile, perhaps even hyper-Agile; particularly when it comes to the customer feedback aspect of the Agile methodology.  The developers do see the benchmarks regularly on an open source project and can provide one another with feedback quicker than is often gathered from end users.