On Being Open : May 16, 2007

Previous Next

0

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]

0 Comments 0 References Permalink