Here is my talk from Apachecon 2011. It was entitled “How to Talk to Your Boss about Open Source (Without Creating a Monster)”. This post contains an embedded audio player which links to a SoundCloud recording of my talk.
I gave a deposition in a case involving contract law a few years back. It’s a long story, but the company I worked for signed a vauge contract with an individual who didn’t deliver a product in line with the expectations of the company. In addition to that point of contention, the contract was one of those vauge “Joint Development” contracts. I’m not sure who drew up the contract, but I was focused on technology issues. This company hired me to come in, rescue the project, and try to see if there was anything worth salvaging.
There was a wide array of technologies, someone had written C code to handle web requests, drop a file on a filesystem and enter into an infinite loop waiting for another process to satsify a request. I came in, took one look at the approach and rendered my opinion – “no way I’m going to be responsible for this Rube Goldberg machine disaster”.
That’s where I started to become exposed to this lawsuit between the contractor and the company I worked for. I was carted into a deposition to answer some questions about open source, licensing, contract definitions, and it was also a chance for the contractor’s lawyer to try to attack my qualifications. That’s always a lot of fun for me because 5 out of the 10 “bios” for me on the Internet are less than serious.
Take this bio from my Apachecon 2011 talk:
Tim used to contribute heavily to Commons back in the days of Jakarta, and he desperately wants to get back to coding and contributing to ASF projects. He’s continuously trying to convince people that he’s a coder, not a technical documentation expert. In addition to open source work and documentation efforts, Tim has implemented systems for Forbes, Inc. and TheStreet.com over the past decade and he has occasionally pretended to be a journalist for O’Reilly Media covering science, government, and technology.
At the time of this particular deposition, I had a bio on O’Reilly that said something like,
“Tim discovered programming on a TRS-80, and went on to study (and subsequently forget) Electrical Engineering at UVA. In his free time Tim likes to sleep, study music, build toys with microcontrollers, and participate in open source projects.”
Innocuous, right? Clearly a joke. Well it turns out that the opposing counsel’s case revolved around the words “and subsequently forgot”. This was going to be the keystone of his attempts to discredit me.
Imagine that you just drove a few hundred miles (at the time I still wasn’t flying – that’s a whole different story), youare sitting in the basement of some cheap Comfort Inn in a conference room converted into a deposition space, and some super serious lawyer hands you a copy of your comic bio. I took one look at this, chuckled, and responded, “Yes, I’m familiar with this biography, I wrote it.”
The back and forth for about 30 minutes went something like this:
Op. Counsel: Mr. O’Brien is it true you attended the University of Virginia.
Op. Counsel: Is it true that you majored in Electrical Engineering?
Op. Counsel: Is it true that you subsequently forgot Electrical Engineering as stated in this bio?
Me: Can you be more specific?
Op. Counsel: That is a simple question Mr. O’Brien could you answer the question.
Me: Electrical Engineering is a broad subject, I need you to ask me about specific ideas and concepts, I’m not here to play….
My Counsel: (interrupting) he just wants you to ask him a specific question, what specifically did he forget.
Op Counsel: Ok, did you understand the basics of electricity. Is there anything you forgot about that?
Me: That’s not a specific question. I can’t answer it. Are you asking about Maxwell’s Equations?
Op Counsel: Mr. O’Brien I’m trying to get you to confirm your own words, words you wrote. Is it true that you subsequently forgot Electrical Engineering.
Me: I remember important concepts, but I forget exactly how to use a Mentor Graphics program to layout VLSI. Do you know what VLSI means?
Op Counsel: Will the court reporter please note Mr. O’Brien’s sarcasm?
My Counsel: He’s not being sarcastic, he’s trying to get you to ask a….
Op Counsel: I think he’s being sarcastic.
Me: I’m happy to answer your questions, I have all day.
Op Counsel: Ok, can you give me time to confer with my client.
Op. Counsel then calls for a break, confers with his client
In hindsight, it wasn’t that I was being sarcastic at all. I think he was reacting to the fact that he didn’t understand enough about technology to understand the sarcasm inherent in my writing. This continues to this day – a non-technical reader may read a post of mine only to conclude that I dislike Maven, but someone more familiar with the topic will conclude that I’m just being tough on Maven because it is so essential to my day to day work.
The pattern established in that back and forth continued all day (it was an exhausting day). Especially when he started to ask me questions about XML, HTTP, and application frameworks in general. Not only was I stopping him with “Your question doesn’t make sense, I can’t answer it.” The court reporter didn’t understand how to transcribe many of the terms. This gave op counsel a disincentive to get into specifics.
Hopefully, I’ll never have to give another deposition again. If I do I’m looking forward to the day that someone asks me about another sarcastic biography. “Mr. O’Brien what did you mean when you said you were pretending to be a journalist?”
Note: I can almost guarantee I’m going to catch some flack for writing this post. Someone’s going to show up and tell me that it is unfair for me to say this when I haven’t stepped up and contributed to the project. Also, I’m speaking for myself here, not as someone who has contributed to Sonatype’s documentation efforts.
Here’s the risky part of the post. I’m not at all excited about Maven these days. It isn’t something that I wake up every day and think, “Wow, Maven’s come so far in the past two years and I’m really excited to teach another Maven training class and update the content to cover new material.” There’s isn’t much new material coming out of the Maven project recently because the project seems to be mired in this state of deadlock.
I’m sitting here watching Gradle pick up momentum, generating a lot of good ideas, and Maven hasn’t even had a point release to fix known bugs since at least April of this year. The Maven project is sitting still. While Maven might have a lock on the build market now, I think people should get ready for a shift.
I’m sick of it. I’m sick of the fact that Maven developers have this absolute allergy to ease of use. Here’s a use case that I’ve had about a hundred time each month over the past four years.
- Set up a new development machine
- Install Maven
- Configure your Maven instance to hit a URL in Nexus
If you use Maven, and if you use a repository manager, this is the best practice. It doesn’t matter if you’ve standardized on Nexus or Artifactory, you configure your build to hit a single repository manager, and if your build needs an additional repository you manage these additional sources of artifacts at the repository manager level. Repository Managers give you a single place to upload third-party artifacts, cache proxied artifacts from public repository, and start to enforce standards.
Both JFrog’s and Sonatype’s business depend on making it incredibly easy to set up this particular configuration variable. So, how is this done in Maven? Using Maven Settings – right, it’s easy just drop a 40 line XML file into a hidden directory off of your home directory. What do those 40 lines of XML do? Easy, they define two dummy repositories, a global mirror, and a default profile.
That’s what I’m sick of both documenting and support. What should be the easiest thing in the world is a process that involves copying a cryptic XML file, customizing a URL, and then explaining how the settings.xml file also abstracts the server credentials into a separate servers element.
Most people don’t care enough to read past the download and install directions and now they are being asked to throw around XML. It doesn’t work, and because of this not as many people use a repository manager as should.
80% of the people that use Central, don’t bother to use a repository manager. I think I know why. It isn’t that installing a repository is difficult, configuring your build tool to use one is a royal pain… We’ve got to figure out a better way.
How about an environment variable? Want to configure your Maven builds to use a Nexus URL for all remote requests? Just set the maven_proxy environment variable.
I’m creating a branch and implementing this because I’m sick of writing these instructions. Onward.
For this post, assume that the primary advantage of open source is the fact that someone, much smarter than you can show up and contribute code that extends your open source project. You might have a great idea for a repository manager (like Nexus), so you release the source code until some open source license, and someone else comes along and extends it to support an unexpected repository format (nexus-yum-plugin).
To me, this is the reason why Open Source works. You expose your code to the world with the hope that someone comes along and takes your idea, develops it, and extends it. If you are smart you’ve defined a good plugin model (like Jenkins) so that people can extend you initial idea without having to invest too much time in learning about internals.
If you maintain a project, I think you have a critical choice to make DVCS (like git or mercurial) or a Centralized option such as Subversion. This choice encourages a certain type of innovation:
- If your open-source project uses a centralized source control system like Subversion, you are presenting potential contributors with an obstacle. Branching and merging with centralized VCS like Subversion (or even CVS) was and continues to be difficult when you compare similar operations to DVCS. Let’s pick on Subversion, when I used to use Subversion for larger projects, branching and merging felt like an awful process: first it was almost impossible to do it right unless you had access to the repository and could create a tag or a branch, second I can’t tell you how many times contributions were clobbered because the interfaces available were just awful.
- If your open-source project uses a decentralized source control system like Git, you are telling potential contributors to, go ahead, innovate on your own improvements, pull and merge changes from the upstream repository, and, one day, surprise us with your own pull request. Innovate on your own terms, and don’t ask for permission. Branching and merging with Git is a few orders of magnitude easier because you are not dealing with tags and branches as directories in a shared repository. You don’t checkout a particular revision, you clone the entire repository.
On one side of this debate, Subversion, communities based on it tend to be as centralized as the SCM. On the other hand, Git, communities based on Git tend to attract contributions from a wider audience, and an audience that isn’t as focused on making sure they are in agreement with the initial community.
In my experience, Subversion encourages a political organization: project leaders that set the direction of a closely held project. Git encourages a more open organization. If someone has a good idea, they can work in a branch in a way that is more natural.
If you are looking for the easiest way to get started with Nexus on an Ubuntu machine, run the following commands. I’ve just updated this package to install Nexus 220.127.116.11:
sudo apt-get install python-software-properties sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner" sudo add-apt-repository "deb http://build.discursive.com/apt/ lucid main" sudo apt-get update sudo apt-get install nexus-oss
Here’s what my package does: it drops Nexus 18.104.22.168 into /usr/local and puts the sonatype-work directory into /var/lib. It redirects log files to /var/log/nexus, and places the temporary files in /var/tmp/nexus. It depends upon (and installs) Apache 2 + the mod_proxy module. It enables the proxy and proxy_http modules and then drops an Apache configuration file with directives that expose Nexus via Apache on the path /nexus. It then adds Nexus as a service.