On Being Open

Being Open. Being Inclusive. Being Human.

stevecarl — Sun, 24 Feb 2008 02:24:41 GMT

Over the years I have had somewhat mixed results reaching people with various points in my blogs. I usually work pretty hard to set the stage for a position I am about to take. In some cases, I have written an entire series of posts before coming to the main point. Not everything is easy to say. Not everything can be functionally decomposed into byte size morsels.

A recent example was a post I did over at TalkBMC. I tried to set up the framework of what I was looking at and why, but I came across some comments in another forum about my post and it was clear that I had not succeeded. At least not for the people inspired enough to respond in the forum. The comments were all over the place: Anywhere from "So What?"(which is fine: The subject was specific enough that if one was not affected the post was probably not interesting) to one like "What a loser, he spent all his time saying this and that". i wondered if they had read the post I had written at all. I went back and re-read it just to be sure. Nope. I had not said what they thought I had. Yet other people had gotten the point. How had that happened?. The ones with the negative reactions often focused on the bad things, ignored the caveats and background info, and reacted. That was just what pressed their buttons.

For some people, The feeling was I was calling their baby ugly. No.. More like:

"Hi. I like your car" I bet that gets good gas mileage. Hey, I also like your iPhone, the case you have, the headphones, your nifty hairstyle, awsome sunglasses, and those shoes you have on. Wherever did you get those? Whats up with the socks though?"

"Socks! Why do you hate on my socks? These are my favorite socks. There are two of them and they fit my feet and ... and.... and... what is so great about your socks anyway? Have to chase that person far to get them?"

When I think about all the open source projects out there, and even just the ones here that are related to monitoring and managing systems, I sometimes wonder at all the energy that has led people to go off into so many different directions to solve the same problems. Part of it is simply that there is more than one way to solve almost anything of course. I am pretty sure that another aspect is human emotional needs entering into and interferring with the other goals of what is otherwise supposed to be an inclusive project. There seems to be a common trajectory (or maybe small set of possible trajectories) to Open Source projects. and it looks something like this:

Someone gets an idea, or has a need and works to create a solution to it.
They want to share their idea / solution with others
If it catches on, sooner or later it hits critical mass and enough people are involved that they start to pull different ways. They may do this based on their own needs, their own ideas not being accepted by the core group, or suddenly thinking they have some advantage heading off in their own way. Schism. Division.
Soon there are multiple solutions to the same problem. There are probably good things about each one, and also probably problems with each approach.
Maturity is reached where things come back together. Or Interoperate. Or things start to die.

Here are three examples I am thinking of:

Compiz / Beryl: They split, and Compiz created Beryl in the same sense that certain greek gods used to be born, spring from the cracked skull of a parent. But now they are back together than Compis Fusion is the result. We all won on that one.

Gnome / KDE: They could not agree on a core tool set and they split, with Gnome springing from to propritary (at the time) clutches of Trolltech. They did not interoperate well at first, despite both being X applications. Later they came to a peace and found ways to let each others applications run inside their environments. Again we all won.

Evolution / KDE PIM: Evolution created the Connector. The Connector let one attach to MS Exchange. KDE updated to Kontact to do a similar trick, but stopped half way through development. Connector was open sourced, but KDE did not adopt any part of the Connector code. Kontact stayed in its half way state, while KDE focused on other things like look and feel and integration of KDE and a new major release of the desktop. No one won there. There is still only one native application way of getting at your calendar from Linux.

But I bet you could point at examples of the same thing inside of Open Systems management. What are they, and how do we head them off at the pass? How do we make sure we work together now?

Egoless Programming and Open Source

stevecarl — Thu, 17 May 2007 01:11:20 GMT

This one was originally posted at:

http://talk.bmc.com/blogs/blog-carl/steve-carl/egoless-programming-open-source

In a recent post I talked a bit about the various meanings and confusions of the term "Open Source". It was a long post, but it really only scratched the surface. of the subject. In this post I will most likely use the lower case version of the term unless what I am referring to is something specific to an Open Source project like Linux or some other Open Sources licensed endeavour (GPL, MPL, etc.).

Along the way of the last post I alluded to several other things the about open source that are things I plan to sooner or later return to. Things like open source as a feedback mechanism regarding what people / customers really want out of their software.

I did not really spend any time in that post talking about what the people that create open source get out of it. I guess you might lump 'companies' into that as well, but what I really had in mind here was the classical concept of Egoless Programming, as espoused by Gerald M. Weinberg in 1971 in the classic "The Psychology of Computer Programming" (Looking at Amazon I see there is a Silver Anniversary Edition out now...).

The Coding Horror website has a great summary of the principals on their web site. In summary, the '10 Commandants of Egoless Programming' are:

Understand and accept that you will make mistakes.

You are not your code.

No matter how much "karate" you know, someone else will always know more.

Don't rewrite code without consultation.

Treat people who know less than you with respect, deference, and patience.

The only constant in the world is change.

The only true authority stems from knowledge, not from position.

Fight for what you believe, but gracefully accept defeat.

Critique code instead of people—be kind to the coder, not to the code.

If you have ever read any forum about Open Source projects, it would be easy to think, on the surface that every one of these commandments is null and void. There are flame wars. There are people being nasty to each other over minor points of style (No one ever puts a comment in that way anymore? Where have you been?). Egos are on parade. "My code is better than your code" taunts are often flung like insults at a wrestle-mania event.

Dig a bit deeper though and I think you will see that all of these things are working. The people with true knowledge and ability tend to become known and recognized. The people with little ability but loud voices tend to be marginalized.

Often the noise is not on the actual developer forum (being it an email list, an online discussion forum, an IRC, or whatever), but on a site or forum related to the project. The noise is on some sort of public facing forum, but not the place where the people collaborating are doing their actual work. This is sad, because it creates a perception about the ways various Open Source projects work that more than likely is not accurate.

In a sense, this is "Those who can, do. Those who can't, comment". Ego is everywhere to be found along that spectrum.

Distilling Weinberg's book into an idea about programming being egoless is probably a bit of a misnomer though. At the end of the day, it is all about ego, and what it takes to satisfy ones own. People who do long hours of thankless charity work and expect nothing for it are still doing it because it is what makes them feel good. It is what satisfies their personal needs.

People are hardly all of a kind, and what motivates one person can be as different as night and day from another. Stereotypes would have it that all salespeople are aggressive, All successful jocks are lousy with money, and all geeks are socially inept loners. Stereotypes are based on some true things, but they are all surface. Scratch the cover a bit to find the commonality. Example: Everyone wants to feel successful even if what makes them feel that way is different. I want to feel like I have written a good weblog entry right now. Others would rather walk over broken glass than write any weblog entries. Writing a weblog would not be rewarding to them, even if it was a requirement of their job.

Take the geek stereotype. I know it pretty well. I am by nature painfully shy. That fits the stereotype to a T. I have over the years worked very hard to be less shy. To write this weblog, and to present at places/events like LinuxWorld and SHARE. Despite all my efforts in this regard I can't in some ways go against my basic nature. My presentations are not action packed, high energy affairs where at the end the attendees walk out wanting to dance. I am happy if we have an interesting session with lots of good conversation about the subject at hand, so that we all learned something. I like to learn new things. I like to meet interesting people.

My favorite sport is snow skiing because it is not me against anyone else. It is me against me... and maybe a mountain. It is a sport that contains breathless beauty and deep joy. I like to ski in part because I like to stand on top of snow covered mountains and look at the other snow covered mountains.

All around me on the top of the mountain are my fellow skiers. Some are racing each other. Some are working on tricks so they can win competitions. Some never stop to look at the scenery, except to read the signs to the nearest double diamond. We are fellow skiers, in the same place, doing more or less the same thing (staying alive on steeply angled ice with slick boards strapped to our feet), but having a different experience from it.

In every case, people are doing what they do because that is what it takes to satisfy their themselves. Their ego. The two are interwined and in many ways, they are the same thing.

If I write a tool (pick a tool, any tool), and someone else finds it very useful, then it meets several needs. First of all, I was probably trying to solve a problem I was having or learn a new thing. Second of all, the act of writing the code, like the act of writing this weblog, is a creative affair. When the code or the entry is going well, and I feel like I am solving the problem or effectively communicating, then I feel good. My need to create is being satisfied, therefore my ego is happy. Then, when someone else finds my tool useful, I get an even nicer feeling stroke. Even if they are not saying this, it is like they are saying "I like you".

That is a basic human need. Everyone wants to be liked, whether they admit it or not. Sure, there are some people I could care less if they like me or not. If I don't care for or respect them, then their lack or like of me is pretty tolerable. If what they value seems so utterly alien to me that I just can not connect to them on any level, it may be a failure on my part to find a common ground. But it is highly likely that at some point I will stop trying to find any common ground.

All you have to do is praise a child's picture to see the entire thing in action. The look on their face, and the torrent of new pictures that ensue will tell you all you need to know about ego and what satisfies it, and the creativity that can flow from satisfying it.

One of the powers of open source is that it, more than other forms of programming, fills a basic need in the code-creative person. Even better, it allows for people at all levels of skills, time, and creativity to contribute and be a part of something bigger than themselves. Something they created is being valued by others, and their name is in the comments and the CVS/Subversion check-ins.

People (even us geeks) are social animals. Ego can be satisfied even if you are not the the only one doing the creating, or the very best. Creative needs can be met by being part of a team or group that created something bigger. The creative interactions inside the team can reinforce all that they love about creating code. If the end result is well received, then that feels even better.

I liken this to when I was at NASA. My companies subcontract had ended, and the new company was not hiring yet. I had to take a new job outside NASA (actually, my only job in the Gulf-coast centric "oilpatch" industry), and I was sad that I had to leave the space program behind to put bread on my table. Then the Challenger accident occurred, and shortly after that, I got a call from the new subcontractor about whether I would be interested in returning to NASA and doing that work again.

I do not like to move around between companies a great deal. I have been at BMC for 18 years for example. I had only been at my then current oilpatch job for 5 months. My ego's need is in part to be a reliable person. This was being put in direct opposition to my need to be a part (a very tiny part) of putting the space program back on track. What I was going to do at NASA was not even obviously directly involved with return-to-space. I was a mainframer, and my work would be on support infrastructure like the email system and the computer that had the shuttle parts database on it.

It was a no-brainer. Even though it hurt to do it, I resigned immediately and went back to NASA. One need trumped the other. At NASA, everyone I know, or knew back then, feels like they are contributing to the bigger goal. I will always be proud of that time, even as I still twinge at my short service time at the oilpatch company.

This was originally published May 16th, 2007. Original Link here:

talk.bmc.com/blogs/blog-carl/ steve-carl/egoless-programming-open-source

This operated as a sequel of sorts to "What is Open Source"

So: Is open source egoless? Yes and no. Being a part of an open source project is probably not about personal glory. Example: The Linux kernel has a few superstars like Alan Cox or Linux Torvalds, but thousands of people have contributed over the years.

The "commandants" about Egoless Programming are more about how to structure the coding projects so that everyone knows the rules of the road. How we are going to work together to get something done. I think they are something like the rules to a team sport. The rules not only set up the inter-team conflict, but they also dictate how each person on the same team must play together in order to win. You may have an MVP or two, but without the team, it is not going to get done. Nothing gets the stadium rocking at a baseball game like a well turned double or triple play. The team working together as they should. A no-hitter is technically a huge achievement for a pitcher, and it might seem like no one players other than the pitcher and catcher were even needed on the field that day, but the whole team has to be there. And the fans are usually bored out of their minds till the end of the game, but that is a different problem.

Open source works because the rules of the team work to meet the needs of the people on that team. Egos and all.

Read more…[What is Open Source|http://beta.openmanagement.org/blogs/stevecarl/2007/03/26/what-is-open-source]