The Fall Guy (or Representing Open Source in the Business)

The problem with being the developer who can write at an open source company is that you end up being enlisted into the whole “Please explain how open source works” discussion when the company hires non-technical managers.  You end up as the representative of this strange thing called “open source.” A VP (not yours) calls you up and says, “Hey, could you explain what open source is to our sales team?”

You seize upon this as an opportunity to spread the Gospel of FOSS. You prepare elaborate slides that speak of Cathedrals and Bazaars. You turn some Lessig into an inspirational dramatic monologue that will inspire these non-developers to start thinking of OSS as the heroic effort we are mounting to take back control from proprietary vendors and create an even larger sharing economy. You think that maybe it is appropriate to introduce some of the developers that work on the project that company is currently making money…

…and then you show up at the “Sales Kick-off” meeting and you realize that this is more of a Glengarry Glen Ross joke festival than it is an audience receptive to the idea of profiting from a sharing economy.  You quickly try to revise slides about “Free as in Beer”, because you realize that any mention of beer is going to get this crowd derailed pretty quickly. They scheduled you at the end of the day, after the VP of Sales gave a speech that involved football metaphors and after the regional sales director had a loud fight about territory with the sales team.  You realize that no one really wants to hear about OSS because they are all about to go out on some sales team-building exercise that involves a lot of drinking and more discussion of sports.

You are summoned to present with “…Ok, some hippy developer is going to tell us what this freeware @#$# is all about anyway. Go ahead show ’em how to ‘make it rain.'”

If this is your job, you’ll find yourself in a room full of people asking you questions like “Alright, so do you geeks have anything better to do with your weekend?” and “Why are my customers getting all worked up over open source? I don’t get no commission on this crap.”

Some things that you’ll notice in the reaction:

  • People with a background in business and sales have no idea why you’ve been participating in open source for years.  Not only do they not understand it, some of them discount the entire idea (even if the company was built atop an OSS foundation).
  • Even if you think you’ve explained open source, there’s a large portion of the audience that either wasn’t listening or refuses to admit that it could ever work. (Someone will make a joke about how you are a communist.  It will be unclear whether that person was really joking or not.)
  • Jokes will be made about open source being about “free love,”, “hippies,” and “unicorns.”
  • Invariably, someone from the 1980s will show up and talk about how they once made a lot of money selling business software.  This will be used as an attempt to show others that your generation just has it all wrong.

If just the right kind of manager is there, everything you say about the “possibilities of open source” will be dismissed as over-idealistic nonsense.  Even though you might have just delivered a presentation on how Hadoop has created billions of dollars in value and how organizations like the Apache Software Foundation act as foundries for innovations that drive computing, someone will invariably stand up right after you and say, “Ok, enough about this open source crap, how are we going to make money?”

You realize that your “open-source” stuff is just going to be used as a scapegoat for a sales team that has no idea what OSS is.  This is the reason why you see headlines about large companies canceling support for OSS projects and products.  It isn’t because they couldn’t find a way to “monetize” – no it was often because they refused to understand the gold mine they were sitting on.

Four Things your Open Source Project Isn’t Doing (But Should)

Choose someone to be responsible for audience measurement and community relations.   Up until now OSS projects have taken a “if we build it they will come” approach to attracting an audience, but there’s so much noise out there these days, it takes real effort to create sites and experiences that lend themselves to easy adoption.

Why should you care, this is open source after all?   Open source projects without an audience tend to wither, and if you aren’t attracting a certain number of new users you can almost bank on the community evaporating over time.  Even your most ardent supports will change jobs or maybe lose interest, having families, get busy, and move on.    You need to work to attract a audience not just for the sake of making some statistic go up, you need to attract an audience and make sure that you measure the health of your audience on an ongoing basis.  Measuring open source projects and gathering audience statistics is something more OSS projects should do.

1. A/B Test the Intro Message – Let’s take the case of a build tool that I used to be interested in, Maven.   Stephen Connolly proposed on the Maven dev list that he wanted to change the message from “Maven is a project management and zzzz….” to “Maven is *the opinionated* build tool.”   If I was involved, I would have jumped in and suggested that he use Optimizely and run an A/B test on that message change.    Test everything and don’t let anyone make subjective guesswork out of something that could be easily measured.  That would have immediately led to a discussion of what the metric for success would be, which leads to #2….

2. Define Metrics for Success – Measure statistics like unique visitors and download numbers and keep a disciplined approach to measuring these numbers over time.  When you run an A/B test using a tool like Optimizely, make sure that you measure the success of the test against these metrics.    Have a report that is generated weekly,  monthly, and annually which captures audience numbers and success metrics (like downloads or mailing list signups).  Share this information with the committers, make them aware of larger trends.

3. Analyze and Refine Analytics (maybe Openly) – Analytics can be dangerous as it is easy to just slap a Google Analytics code on a page and call it done.  If you do this without thinking about canonical host names and making sure that your pages are instrumented correctly you can end up with analytics numbers that are off by a factor of 2x or more.   Analytics is so far from easy, even if you are running it, there’s a good change that you are doing something wrong.   If you run an OSS site, make sure to make analytics (and tending to analytics) a regular task.   Analyze these reports without preconceptions and identify trends in usage.    You likely publish documentation online: do you know what the most important page is?   Do you know how people end up on your site?  What’s the most popular search term?    How many people responded to your launch announcement?

One more thing, if you are an open source project, why not publish your analytics reports publicly as a way to recruit more help?   Transparency is the best publicity.

4. Report on Social Interactions, Monitor Twitter – Pay attention, the worst thing that can happen is someone having a problem with your tool and you missing out on an opportunity to help.    You shouldn’t just rely on contributors to do this in an ad-hoc sort of way, you should have a measured and well-thought out approach to monitoring Stackoverflow, Twitter, LinkedIn, and (possibly) Facebook.      Tools like Hootsuite can help.

I know that some developers read this and think that this is all silly marketing bull.  It isn’t.   What is bull is pretending that attracting an audience doesn’t matter, and that you are just working on OSS because of your own self-interest in code.   In my experience, you are working on OSS because you are trying to attract others with similar scratches to itch.   A bigger community of users results in a healthy pool of potential contributors.   Open source projects, especially those at foundations like Apache and Eclipse, need to get comfortable taking a more aggressive approach at attracting an audience and they need to stop depending on vendors to do this work for them.

Loukides: “The winner in the case isn’t just Google; it’s all software developers”

Mike Loukides sums up the end of this phase of the Oracle v. Google trial in the title of his piece on Radar: “The End of a Fishing Expedition”.

First, Mike is right, as he very often is, but this sentence gives me pause:

The winner in the case isn’t just Google; it’s all software developers, who don’t have to worry as much about creative interpretations of copyright law, and are free to develop compatible implementations of an API.

Yes, Alsup’s decision is something of a victory for Open Source and people interested in compatibility, but Alsup also mentioned something in the summary that I’m still trying to understand:

This order does not hold that Java API packages are free for all to use without license.

While this was a win for Dalvik, Java is still confined in this annoying “box”. OpenJDK is open source, but the language and is still gated by this TCK. I have yet to see any analysis from people I trust (aka groklaw) on this topic. Java still isn’t free, but, at least, there’s no barrier to people creating an alternative implementation (they just can’t call it Java).

It will be interesting to see what an Oracle scorned does to the licensing terms it uses to distribute Java. While the APIs are not copyrightable, my lawyer friends have told me that there’s not much limit to what Oracle could put into a EULA that accompanies the JDK. (Just look at how Apple uses the EULA for the iOS SDK for proof that anything is possible.) If they are rational and want the platform to succeed they won’t do this, but I’m worried that now that Java isn’t as lucrative as they thought it was that they might just discard it (and ruin it in the process).

I also fear the appeal. I’m a pessimist, if this case makes it to the Supremes all bets are off.

I do agree with Mike, Alsup is something of a modern hero.

Another Online Cookbook: The Lift Cookbook

Check out the Lift Cookbook an online cookbook for the Lift Framework. This is an open source book covered by Creative Commons Attribution, Non Commercial, No Derivatives. The book has a Twitter account @liftcookbook. The GitHub account is here (11 watchers, 4 forks) and it appears to be under Richard Dallaway’s account, and from the Impact graph this appears to be a four person effort: Jane Dallaway, Diego Medina, and Mads Hartmann Jensen.

Two quick things about this book: 1.) Awesome to see another free book, Google loves free books, and the cookbook format will generate a steady stream of hits because it is SEO friendly. 2.) It’s web-friendly (unlink my book at the moment) in that it is page oriented and doesn’t suck all the life out of the experience by forcing you to deal with sequencing issues that accompany the printed artifact. #2 in plainspeak: You can read a page like this without ever having to see that it is Section C.2. In other words, you can experience the content as an isolated page.

One more thing, that Table of Contents on every page approach isn’t going to scale very well, and my advice to the authors would be to put Google Analytics on this thing. Online books provide an opportunity for you to get instant feedback on what works and what doesn’t. It will also surprise you what pages end up getting the most traffic. For example, the most popular page in the Commons Java Cookbook is a page that deals with Multipart POST uploads with HttpClient, who would have known were it not for Google Analytics? Also another piece of unsolicited advice: put a copyright notice on every page, really.

Most importantly, here are instructions on how to check out the source code from (of course) Github and submit patches.

Use the Creative Commons License for Free Books

One important thing to consider if you are planning on writing a free book is the license for the work. Traditional software licenses have some clauses that are not relevant to books or electronic media. Lessig’s Creative Commons makes sense because he wrote it with books in mind. So where a license like Apache or GPL talks about “binaries” and “source”, Creative Commons talks about “works” being “published”. Even though the books I write have DocBook source code which is compiled into binary output, the Creative Commons talks about “Work”.

Here’s the definition of “Work”, which I find amusing because it mentions “circus performers”. I often wonder if one of the Creative Commons folks put “circus performer” in the definition of Work on a dare:

“”Work” means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; … blah blah blah …; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.

I write books under:

Which is very simply explained on the Creative Commons web site as:

“This license is the most restrictive of our six main licenses, allowing redistribution. This license is often called the “free advertising” license because it allows others to download your works and share them with others as long as they mention you and link back to you, but they can’t change them in any way or use them commercially.”

Most of the books I write have some sort of commercial interest associated with them. For example, I want to make money as a consultant or as a trainer. Or, the sponsoring company wants to sell a product or training. Although I know the next part of this sentence will appear invisible to Free Software Foundation people, I’ve found it necessary to have a protective No Derivatives clause for technical document as I’ve already had instances where content I’ve written has magically appeared in someone else’s (lucrative) training material.

If you’ve written a technical book, you are also very familiar with the idea that there is no control. Someone is going to take your content, muck around with it, provided it as a free download on any one of a hundred sites designed to pirate books. Any selection of a license is really just aimed at people who are going to follow the rules.

Clauses

Here are the clauses I choose, and why…

Attribution – Just makes sense. Not controversial with anyone, right?

No Derivatives – I’m a bit old-fashioned, I feel like a book is a complete work. And, I don’t want people picking and choosing parts of the book to publish. I’m also not particularly keen about people jumping up and creating a derivative work that rides off of a work I’ve helped create.

Non-commercial – This has a few meanings in the context of a technical
book. It means that no one but the originating author (or sponsor) can sell the book as a part
of a commercial offering. Someone else could sell the book at a
reasonable cost like printing plus materials plus labor costs, but most people don’t want someone to take their book and start selling it in some expensive package deal at least some discussion about licensing.

The other part of Non-commercial is that someone can’t purchase ten
copies of your book and then use it as a basis for a training class.
This is tough to enforce, and I’m not sure you could realistically enforce this.

If you are more into the GPL
side of life, you could drop the No Deriv / Non-commercial, and go
with a Share Alike clause.

Conclusion

If you are thinking about starting a free book, think about the different clauses that are appropriate to your situation and choose wisely. Some of the clauses I listed above are far too restrictive for most open source work, but, if you are starting to write a book, you’ll want to think about these issues.

Unintentionally stirring a bee’s nest (by suggesting Maven)

I just had an odd exchange, someone has a great piece of open source software that I totally depend upon, it’s a complex beast of a thing, and I wanted to a.) express gratitude, b.) offer some help with the build. You see the build for this particular system is an Ant build script with a preamble of instructions, and the project itself is this megalith of code in one big src/ directory. Every time I want to use some new component that is in development, I have to download someone’s tarball, uncompress the thing and then fish around for JAR artifacts to upload to central. Some of the JARs that are included have specific Subversion revision numbers in the JAR file name. This makes using the binary artifacts from this particular project a royal pain in the neck.

I follow the project, I’m invested in the code, I thought it might make sense to *ask* if there was *any* interest in migrating the build to Maven on the grounds that it might make it easier for people to contribute and participate. Now note, I didn’t volunteer to switch the build the Maven, I simply “asked if there was any interest”, and not even on a development list. I asked one of the main contributors directly because I didn’t want to ruffle feathers.

What I got in return was this total tirade against Maven. How it isn’t flexible enough, how this particular person wanted to “send an invoice” to whoever was responsible for Maven because he had wasted so much time on it. Ending with the quote: “If our not using Maven as a build system is a problem for those who
do then it’s not our problem but the problem of Maven for not being
flexible enough.”
In other words, my very diplomatic inquiry was met with “#$@! off”.

Not “it’s been a while since I’ve looked at Maven, here are the problems I had, if you can get it working alongside this Ant build, be my guest…”. Or even, “No, I’m not interested in that. I had some problems in the past, and I don’t think it makes sense to distract from the current development.” I didn’t even get a chance to make an argument on the “merits”. So here it is…

The Argument

  1. If I can’t go to your website and figure out how to checkout the source code and build in 5 minutes, your project is a pain in the neck to contribute to. The casual contributor has no incentive to learn how your build system works.
  2. If, in order to use your library, I have to go download some archive, unpack it and then futz around with JAR artifacts, your project is a PITA to use.
  3. I don’t even care if you use Maven, all I really care about is that you publish regular SNAPSHOT builds to a repository. When I see some development release of a JAR that is wrapped in a tarball, contains a README file, and it bundles with other JARs, I end up having to upload all this noise to a repository manager crafting my own groupIds out of thin air.
  4. Yes, I understand, you hate Maven because it called you a bad name two years ago, and you didn’t know anyone qualified at the time to help you. If you had problems in the past, it was probably because you didn’t understand the tool. No offense. I can probably help out there.

If you disagree with some of the assumptions, that’s another matter.