Tag Archives: opensource

Project Leader

I was recently asked to write something about the project that I work on – RDO – and one of the questions that was asked was:

A healthy project has a visible lead(s). Who is the project lead(s) for this project?

This struck me as a strange question because, for the most part, the open source projects that I choose to work on don’t have a project lead, but are, rather, led by community consensus, as well as a healthy dose of “Just Do It”. This is also the case with RDO, where decisions are discussed in public on the mailing list, and on IRC meetings, and those that step up to do the work have more practical influence than those that just talk about it.

Now, this isn’t to say that nobody takes leadership or ownership of the projects. In many senses, everyone does. But, of course, certain people do rise to prominence from time to time, just based on the volume of work that they do, and these people are the de facto leaders for that moment.

There’s a lot of different leadership styles in open source, and a lot of projects do in fact choose to have one technical leader who has the final say on all contributions. That model can work well, and does in many cases. But I think it’s important for a project to ask itself a few questions:

  • What do we do when a significant number of the community disagrees with the direction that this leader is taking things?
  • What happens when the leader leaves? This can happen for many different reasons, from vacation time, to losing interest in the project, to death.
  • What do we do when the project grows in scope to the point that a single leader can no longer be an expert on everything?

A strong leader who cares about their project and community will be able to delegate, and designate replacements, to address these concerns. A leader who is more concerned with power or ego than with the needs of their community is likely to fail on one or more of these tests.

But, I find that I greatly prefer projects where project governance is of the people, by the people, and for the people.

Living in community: Curbing your passion

1 Comment

I’ve had a very frustrating set of interactions over the last 3 days, on an open source community mailing list. Doesn’t matter which one, because I think that these things are universal.

I said “here are some ways we can make things better.” Or, at least, that’s what I thought I was saying.

Several people heard “everything is broken, and it’s your fault.”

At the end of several very heated email conversations, it became clear to me that we all agreed on (almost) everything, and were getting hung up on that initial statement. It wasn’t even that the things that I was proposing were opposed, it was that the way that I presented them was perceived as criticism of what people had done for the last few years.

Email is notoriously bad at conveying nuance. This is amplified in a multi-cultural, multi-lingual community.  Here’s some practical things that I took away from this conversation – most of which I should have already known

Suggest improvements. Don’t focus on shortcomings

Pointing out breakage is easy. Proposing solutions is where the real work is. Now, sometimes, you need someone to say “this is broken and I don’t know how to fix it.” Those situations are very tricky. Tread lightly.

Focus on what needs improving, not on who made it that way

This sounds easy, but is really hard. There’s always someone who spent hundreds, or thousands, of hours, making the thing the way that it is, and so when you point out that the thing isn’t perfect, that person might take it personally. I honestly don’t know how to avoid that, and this week has shown that very clearly. But I can look back and identify some of the things I did poorly, and apologize for them.

Curb your passion

This one is unintuitive. We need to be passionate about our community. But sometimes when you’ve been pondering something for a few months and arrive with all of that passion, people are more likely to mistake that passion for anger, criticism, and so on.

Yes, some people need to get thicker skins. Don’t read everything I’m saying as that we need to pamper everyone’s bruised feelings. But when people aren’t looking in your eyes, it’s easy to take passion as an attack. We’ve all done it.

I’ll close with one of my favorite quotes from Confucius, who said, “There is honor in the email not sent.”

Yes, he said that. I was there.

Read your email twice before you send it, and delete half of them unsent. This will lead to a better universe, and fewer three-day shouting-fest email threads.

 

Features, not lies

A colleague is attending the nginx conference in Austin this week, and shared with me several anecdotes in which a speaker preached misinformation – or if I want to be generous, grievously outdated information – about Apache httpd, to support the notion that nginx is better.

This led to the following:

 

Each time I have encountered nginx people at conferences, and attended their talks, they have compared nginx to grossly misconfigured, 10 year old installations of Apache httpd 2.2 to support their claim that nginx is leaner, faster, and easier to administer.

Here’s the thing. nginx is a solid project. I have zero beef with the software itself. I have used it myself, when the need arose. What I object to is the habit of the fans of nginx to lie (or exaggerate, or just spout uninformed opinions) to make themselves look better. If you must compare, compare our latest to your latest, and have experts correctly configure each. That way, each will show where it shines, and where it doesn’t.

It is possible to configure ANY software badly. This is why it’s almost always a bad idea for an expert on SoftwareA, who knows little or nothing about SoftwareB, to compare them head to head – they’ll invariably be comparing a well-configured A to a less than optimally configured B. And in the case of nginx vs Apache httpd, these guys almost always use 2.2 or 1.3 as an example of … well, all of the things that 2.4 fixed. 5 years ago.

Any intro to marketing class will tell you that you need to talk about your own strengths more than you talk about the other guy’s weaknesses. This is a message that nginx and presidential candidates seem to have missed. And, in the case of software, it’s even more important, because whereas Donald Trump will always be a monster, every time you point out a legitimate shortcoming in Apache httpd, we fix it.

90-9-1

1 Comment

In a talk I attended earlier this year, Shaun McCance mentioned, as though it was established science (which it is) the 90-9-1 principle of community participation. I’ve thought of it frequently since then, to set expectations and to keep myself sane.

The idea is that in any community effort, 90% of the people are going to sit around saying that it’s a great idea, but not actually doing anything about it. 9% of the people are going to work casually on it in their spare time, as convenient, and between them will do a huge amount of the work. Then 1% of the people – usually one or two dedicated people – will pour themselves into it wholeheartedly, putting every spare moment into making it a success.

Note that it’s not the exact numbers that matter here, it’s the undeniable fact that you can’t expect everybody to work as hard as you do on everything. It’s all too easy, when doing anything on a volunteer basis, to look around and get frustrated, discouraged, even angry, at the 90%. Understanding that this is the normal, expected, even healthy way that communities operate, can help you refocus on what you can (and can’t) do in any given effort.

Sometimes (most of the time) it’s ok to be in that 90%, and you don’t need to feel that you’re not pulling your weight. However, if you’re in the 9% or the 1%, it’s not reasonable to get angry with the 90%. They have other things to do, and are likely the 1% on something that you’re not helping much with.

By the way, here’s a couple of resources about this notion:

This article claims that the concept is dead. Note that this article appears to be someone just making up new numbers to illustrate the same concept. What’s important here, folks, isn’t the exact numbers, but the general concept. Way to miss the point. (This article also appears on dozens of sites in various different forms.)

Wikipedia claims that it’s a feature of Internet culture.

Here’s an actual statistician doing scientific analysis, rather than me making up numbers.

Paul Biondich keynote, LinuxCon Europe 2014

In his keynote yesterday, Paul Biondich mentioned a few numbers – OpenMRS has been in development since 2008, and is deployed in over 70 countries – but mostly, the number he focused on was one – individuals whose lives have been touched by the project. Doctors, patients, and Open Source developers.

I’ve been following OpenMRS for several years, since discovering the project while I was working at SourceForge, and learning that it was started by a visit to Kenya, to a hospital where paper-only medical records were hampering patient care. The trip, which Paul almost declined to go on, changed his life and the course of his career, and he began to devote his time to developing OpenMRS, which is now the standard medical records system in many countries, including Kenya.

Paul observed that medicine is, in large part, an information science. Having access to the right information at the right time can be the difference between the life and death of a patient. Of course, it’s only one tool in the toolbox, but it’s a critical one.

Paul, and all the other people at OpenMRS, have long been an inspiration to me, and represent all that is good and noble about Open Source. His keynote is well worth watching once the videos are posted.

 

Indoctrinating the youth

2 Comments

I think, this morning, my son finally began to understand the awesomeness that is Open Source. He asked, as he has done a number of times before, what it would cost to set up a website, and didn’t seem to believe my answer, which was, of course, $0.

So, after he wolfed down his breakfast, we sat down and installed WordPress, got it configured shiny, and he kept asking, how much does this cost? How can it be this good if it doesn’t cost anything? This looks really professional. Are you sure this is free?

I told him, as I’ve probably mentioned before, that the Apache Web Server runs a huge percentage of the websites he looks at, and that I had a part in creating that. And that I also had a *very* small part in creating WordPress, too. (I believe I have two patches in there somewhere, although I don’t remember what they were.)

At one point, while we were tweaking the theme, he said, in a very roundabout “I’m sure this is way too hard” kind of way, that some day, in the distant future, he’d like to have forums on the site, where people could discuss things. I installed BBPress in under a minute, and said, you mean kinda like this?

He also asked whether it was possible to have his own hostname, and so I taught him a little bit about how DNS works, and showed him how to register a name, and then how to configure DNS to point a name at an IP address.

So, about 30 minutes later, he’s got his own website, where he’ll be posting his youtube videos, animations, and random comments about the world. No, I don’t really know what the name means, so ask him, not me.

Apache httpd at ApacheCon Budapest

tl;dr – There will be a full day of Apache httpd content at ApacheCon Europe, in Budapest, November 17th – apacheconeu2014.sched.org/type/httpd

Links:

* ApacheCon website – http://apachecon.eu
* ApacheCon Schedule – http://apacheconeu2014.sched.org/
* Register – http://events.linuxfoundation.org//events/apachecon-europe/attend/register
* Apache httpd – http://httpd.apache.org/

I’ll be giving two talks about the Apache http server at ApacheCon.eu in a little over 2 months.

On Monday morning (November 17th) I’ll be speaking about Configurable Configuration in httpd. New in Apache httpd 2.4 is the ability to put conditional statements in your configuration file which are evaluated at request time rather than at server startup time. This means that you can have the configuration adapt to the specifics of the request – like, where in the world it came from, what time of day it is, what browser they’re using, and so on. With the new If/ElseIf/Else syntax, you can embed this logic directly in your configuration.

2.4 also includes mod_macro, and a new expression evaluation engine, which further enhance httpd’s ability to have a truly flexible configuration language.

Later in the day, I’ll be speaking about mod_rewrite, the module that lets you manipulate requests using regular expressions and other logic, also at request time. Most people who have some kind of website are forced to use mod_rewrite now and then, and there’s a lot of terrible advice online about ways to use it. In this session, you’ll learn learn the basics of regular expression syntax, and how to correctly craft rewrite expressions.

There’s other httpd content throughout the day, and the people who created this technology will be on hand to answer your questions, and teach you all of the details of using the server. We’ll also have a hackathon running the entire length of the conference, where people will be working on various aspects of the server. In particular, I’ll be working on the documentation. If you’re interested in participating in the httpd docs, this is a great time to learn how to do that, and dive into submitting your first patch.

See you there!

Copyright statements in source files

Earlier today I was looking at a source file for the Ceilometer docs and noticed that there’s a copyright statement at the top.

Now, in no way do I want to pick on Nicholas. There are hundreds of such copyright statements in the OpenStack docs and code, and this is just the example I happened to be looking at.

(Note that my employer has its share of copyright statements in the OpenStack code. Pretty much every company participating in OpenStack does this. I think we need to stop.)

I sent a note to the OpenStack-docs list, and it has generated a thread of remarks.

As I understand it, people are encouraged to put copyright statements in contributed source code and documentation, and add copyright lines to files that they modify.

I believe this to be a very bad thing to do, for the following reasons:

* If I edit a file and it says at the top that the file is copyright BigCo, I am discouraged from editing that file, because of the implication that I’m treading on someone else’s toes. Files should not have any indication that they are “owned” by any one person or company. (See this by Karl Fogel for more on “owning” code.) This actively discourages people jumping in and fixing stuff.

* If N people contribute to a file, are we supposed to have N copyright statements in the file? This doesn’t scale over time. Imagine what these files will look like 10 years from now, and fix the problem now.

* Having author names in a file encourages people to contribute for the wrong reasons.

* Git keeps track of who contributed what changes. It’s not necessary to have explicit copyright statements.

The first of those reasons is, to me, the most compelling. Anything that discourages contribution, particularly from beginners, should be eschewed as much as possible.

I have had people ask me, when encountering a copyright statement in source code, whether they have to ask that person’s permission before submitting a patch. If we can avoid even one person asking this question, we’ve done a service to the project.

I also worry that companies that insist on copyright statements in their contributions understand neither copyright law nor Open Source. On the one hand, the audit trail in Git protects your record of contribution, and thus your copyright. On the other hand, if your copyright is that important to you, perhaps you shouldn’t be contributing it to an Open Source project. It’s anti-community to say to a project that they can have your contribution, but only as long as you get to assert that it’s your personal property. Open Source is about community and collaboration. If the building is owned by the community, what do you gain by insisting that a particular brick is yours?

At the Apache Software Foundation, we had this debate a decade ago, and decided that author tags in source code were anti-community, and thus discouraged. To quote from the thread of comments at the time, and, in particular, to quote Sander Striker:

At the Apache Software foundation we discourage the use of author tags in source code. There are various reasons for this, apart from the legal ramifications. Collaborative development is about working on projects as a group and caring for the project as a group. Giving credit is good, and should be done, but in a way that does not allow for false attribution, even by implication. There is no clear line for when to add or remove an author tag. Do you add your name when you change a comment? When you put in a one-line fix? Do you remove other author tags when you refactor the code and it looks 95% different? What do you do about people who go about touching every file, changing just enough to make the virtual author tag quota, so that their name will be everywhere?

There are better ways to give credit, and our preference is to use those. From a technical standpoint author tags are unnecessary; if you wish to find out who wrote a particular piece of code, the version control system can be consulted to figure that out. Author tags also tend to get out of date. Do you really wish to be contacted in private about a piece of code you wrote five years ago and were glad to have forgotten?

This is a slightly different issue (author tags rather than copyright statements) but makes exactly the same point. Do I add a copyright statement when I correct grammar or spelling in a doc? How about when I add a paragraph or reorder sentences for greater clarity? At what point do I remove your copyright statement because I’ve changed so much of that file?

And then of course, you should consider the bigger question – why do you care? What are you trying to protect against? If you’re trying to protect against your contribution being taken by the community and used for other purposes, perhaps contributing to an Apache-licensed code base isn’t the smartest thing to do.

RedHat Summit Summary

Last week I attended the Red Hat Summit in Boston. It was, for me, equal parts pep rally and intensive OpenStack training.

Jim Whitehurst’s keynote was just great, because it reemphasized how much RedHat really *gets* Open Source, at all levels of the organization. So, this part was pep rally for me, and confirmed to me that RedHat is the place where I want to be. Same for Paul Cormier’s keynote. Both of these are well worth watching if you care about cloud computing, IaaS, or PaaS, or expect to at any time in the near future.

I attended a number of sessions about OpenStack, and you can see a wrapup of all of that content in Perry’s blog post about the conference.

And I helped out at the RDO table in the Developers Lounge. In the process I met many of the engineers that I’ll be working with, and I learned quite a bit about RDO and OpenStack, as well as who I need to go to when there’s something I don’t know yet. And I got to play around some with TryStack, a free service where you can experiment with an RDO installation, launch virtual machines, and connect in to them to see how RDO behaves.

There’s a huge amount of interest in OpenStack, and the ecosystem around it is full of really cool stuff. I was particularly interested in OpenShift, with which you can launch a non-trivial webapp in just minutes minutes. Very cool stuff.

Another high point of the week was the RedHat Summit 5K.

RedHat Summit, Boston

There were a few hundred people in the race, which wasn’t a traditional road race, in the sense that there wasn’t any official time keeper, and traffic wasn’t stopped. We had pace groups (I ran with the 8:30 minute group), and a pacer who knew the route. I had set a goal of breaking 27, and I ran a 25:32, with which I was very pleased. This was the first 5k I’ve run since, I believe, 1994, so, not too shabby.

Open Help Conference, 2013

This weekend I attended the OpenHelp Conference in Cincinnati. Unfortunately, I was only able to go to one day of it, as we had to be back for something Sunday morning.

It was smallish, and so there was a lot of good conversation and brainstorming.

The focus was both documentation and support, which are, of course, deeply intertwingled. It gave me a lot to think about, and I really wish I could have been there for the second day as well.

Siobhan McKeown, from the WordPress documentation team, was at the conference, and took amazing notes, so I’m going to link to her writeup for each talk.

The day started with Jorge Castro talking about using StackExchange to handle the Question & Answer part of support.StackExchange is part of the StackOverflow family of sites, Each StackExchange site is focused on a particular community, and is very focused on Question and Answer format, rather than general discussion. It allows users to vote for the quality of questions and answers, and seems to be a great way to get the subject matter experts more directly involved in the support process.

Siobhan’s notes are here.

Following that, Michael Verdi, from the Firefox support team, talked about the SuMo site and the work that they had done to help users find the answers to their question. Of particular interest was some graphs he showed of the improvement in customer satisfaction, as well as the rate of answered questions, brought about by just improving the search functionality, to help users find the right docs so that they didn’t even need to ask their question.

Firefox has their own home-grown, but Open Source, solution, called Kitsune. It has some StackExchage-like features, and also has a great tool called Army of Awesome, which is a way to watch Twitter mentions of your project/product, and ensure that at least one person from the expert community has responded to each one.

Here’s Siobhan’s notes.

This was followed by a panel discussion including Jorge, Michael, Jeremy Garcia (LinuxQuestions.org, and Siko Bouterse from Wikipedia. The discussion ranged from Wikipedia author retention to further discussion of many of the issues that Michael and Jorge had raised.

I spoke next, talking about listening to your audience. This is something I’ve thought a lot about over the years. My trepidation in speaking at this conference was that it seems like many of the people there know a lot more about documentation and support than I do, as I’m largely self-taught in this area. But it seemed that my remarks were well received. Once again here’s Siobhan’s notes, which in this case are way better than my own notes for my talk.

I was the last speaker of the day, and this was followed by a general discussion of the things that had been raised during the day, as well as many related issues.

You can see a lot of commentary about the events of the day, and of Sunday, by looking at the #openhelp keyword on Twitter. I’m looking forward to reading Siobhan’s notes from Sunday’s sessions.