This post is from march 26th, 2007 at TalkBMC, and is originally found here:
http://talk.bmc.com/blogs/blog-carl/steve-carl/what-is-open-source
Ynema Mangum, producer of Podcasts at talkBMC picked up part of this post to title a couple of podcasts Whurley and I did:
http://bmc.media.libsynpro.com/talkbmc/TalkBMC-Steve-Carl-Whurley-20070328-part1 .mp3
http://bmc.media.libsynpro.com/talkbmc/TalkBMC-Steve-Carl-Whurley-20070328-part2 .mp3
One of the nice things about having whurley here at BMC is that it frees me to talk about some things that I have a real interest and passion in: open source. Linux is of course an Open Source project, and that is how I can write an entire entry here about open source and call it "Adventures in Linux" still. That is my story, and I'm sticking to it.
Linux is by far not the first open source "project" I have been around. As a newly minted system programmer 27 or so years ago (geez, I'm old... When did that happen?) I was first involved with a new operating system from IBM called VM/SP. VM/SP was the post anti-trust version of VM IBM created out of VM/370. VM/370 was a free operating system that IBM gave away more or less with their 1970's era mainframes.
What is not at all interesting to me was that the OS's of the day were free, or that they led to the anti-trust issues. What I found interesting was that IBM would let you see the source code. It was right there, on the install tape. Yes, tape. Don't get me started on how old I am again.
One of the First open source (case intentional) OS's
VM was never overly well supported by IBM back in the days of it's birth, but that did not really matter. With the source code the end user community banded together, wrote their own updates and enhancements, created tools tapes that they shared at places like SHARE and via the pre-Internet BBS's. VM came to do and be all sorts of things IBM never intended it to be. It was supposed to be a migration tool. People were supposed to use it to move from one OS version to another without having to buy/lease/borrow an entire second mainframe. Instead, people started using it as their primary OS. It made IBM crazy sometimes. Not the internal at IBM VM folks of course, but others. Before IBM knew it all these innovative new things kept happening. New programming languages and new ways of doing old things. It had an entire life of its own, and no one was in charge. IBM did not control it!
This is not to say IBM did not own it. It was copyrighted code. They were the maintainer of the base version. Many of the modifications the end users were making made it in some form or another into the base code too, with the authors permission. Sometimes IBM would re-implement a new feature that was popular. Inside IBM there were open source aficionados that wanted VM to be what the customer wanted it to be, and worked to get the changes into the base code where it made sense. More than a few VMers did these things on nights and weekends because they wanted to do the right thing for the customer, even if their personal management did not understand what they were up to.
Open source was not a comfortable place for many at IBM though, at the time. There was a strong group of VM haters. They did not get it. Or they did get it and they did not like it. It did not do what they wanted it to do. They could not control it. It had to die.
Another thing happened along about this time that IBM was involved in, lost control of, and took on a life of its own: the IBM PC. More on that in a bit.
It was announced over and over and over that release X or Y or Z was going to be the last one for VM. The end users responded by telling IBM they were not the only game in town, would leave the MF behind for a shiny new VAX or something, and IBM relented. VM lived on, and survived its detractors.
It Just Won't Die!
The next strategy was to make VM closed source, or “Object Code Only”. Another huge customer backlash occurred (I still have an OCO is LOCO button from SHARE back then), and while some modules were made OCO, they were often just the new ones that dealt with the new hardware features of the new MF's. IBM was also fighting off Amdahl at the time and was woofed that Amdahl had faster mainframes and new features like MDF they did not have.
Although not completely congruent IBM also decided to get back control of the PC market they created by coming out with the PS/2. The only thing that was a hit there was the PS/2 style connectors for keyboard and mouse. It is not like IBM never sold a PS/2 but the market chose the more open PC's by and large. IBM lost it's leadership position in PC space. The market chose open over closed.
The market had some new options for MF things. Things other than VAXen. Things IBM created and then lost control of.
Networked, open PC's could be made to do some of the things the MF had been doing to that point.
If IBM was going to take away the VM source, they were going to take away the ability of the customer to make the OS do what they needed it to do. Customers could and did vote with their feet. The new client / server paradigm of the day, where PC class computers could be bought and folks outside the glass house could control their own computing destinies occurred. There are factors at work here other than just whether or not VM source code was available, to be sure. The cost of the MF was a huge factor as well. In general though, if you are going to make your customer mad at you, they will look more aggressively for other solutions. There was a huge outcry about VM and access to source code. IBM was poking their customer in the proverbial eye with the strategy.
What It Means When People Leave, and Never say Never
As an aside, any time the end users start buying their own servers and building their own things, it is probably time for the IT folks to go look in the mirror and see what they are not doing for their customer. But I digress.
All this history is to get around to the ultimate point that open is better than closed, and once you become open you can never become closed again without losing your customer base. I try not to use terms like 'Never', or 'Ever' because few things ever really meet that absolute.
A billion years from now, when the sun continues its slow move towards being a Red Giant star, and it expands and heats up and crisps the surface of the planet Earth, future whurley and future Steve may be observing from an orbital platform, and he'll turn to future Steve and say "I thought you said the would NEVER happen. No one using open solutions down there now!" In the scale of current Steves professional lifetime, this is a case where I think the absolute is more or less true.
The Customer is Always Right
The thing that many at IBM missed along the way back then about VM and the PC was that they were getting incredible feedback about what the customer really wanted from them. What their real needs were. Companies spend millions of dollars doing customer surveys, and here they were voting with their dollars and their own time and code.
IBM is not stupid. I think there is a reason that they corporately became early fans and supporters of Linux. They knew it for what it was. They had taken a couple pretty big licks here. Mostly folks seem to think it was an anti-Microsoft move (because of the whole OS/2 and MS Windows debacle), and there may be some truth to that as well.
I think IBM looked at Linux and knew immediately that Linux was going to be very popular because people could make it meet their needs.
Open source is the ultimate feedback loop for what people and companies want from their computer programs. What people/companies will go so far as to do as to invest there own personal time, effort, and money to create.
The Rainbow of Open Source
Open Source. open source. Capitalized. Not. To this point I have used open source in lower case. The generic term just means that you can see the source. It does not imply any about who owns the code or its IP thereof. To this day, IBM clearly owns VM, and it is still the best hardware virtualization platform on the planet. This will not last. Eventually Xen or something like it will catch up. But not today. Or tomorrow either.
Context is everything when you use terms like 'O/open S/source', 'Web 2.0' or 'You have a new Opportunity'.
"Open Source" in caps. In some ways I see it as being sort of like the term "Web 2.0" or "SOA". Terms with meaning to be sure, but also terms that are horribly tortured and abused and twisted to mean other things that match others peoples needs of them.
I am just waiting for a software product to advertise itself as "Web 2.0 compliant". Probably already has happened and I missed it.
Open Source the License
One way to think of Open Source is the license that a piece of code uses. Some are more open than others, and it really depends on what the author of the code wanted as to what license they might chose to put it out with. This area of Open Source is fraught with land minds for any software company contemplating an open source move, and that is another reason I am glad whurley is here to help guide BMC down the right path. I am not an expert in all the various T's and C's of the various Open Source licenses, but one example of what some of the issues there might be around this is the current GPL V2 versus GPL V3 furor. Dana Blankenhorn's latest ZDNet post was interesting on this subject recently.
The OpenSource website has a comprehensive list of the various OSI approved licenses, and they are legion.
Open Source / open source as documentation
No matter which flavor of open source you are are talking about, one thing it true. When you have the source code, you have the manual to those who can read the language it is in. In R&D Support in various meetings, conversations, or heavy duty problem determination sessions we often internally kick around why a program is behaving a certain way . The most recent one that springs to mind was the recent Fedora kernel update that changed the NFS behavior of a Linux client against an NFS server. The change was to the client, but the problem was the server. To determine that took going into the source code and seeing what it was actually doing. I used to do that all the time back in the VM days too. It is not easy. You have to know the language. It is powerful.
Open Source the Process
Whurley posted a link on our internal wiki to this excellent ONLamp article about what corporations needed to learn from Open Source. I especially loved the bulleted list at the end:
Tell the truth all the time
Trust the team
Review everything, test everything
All developers are created equal
The fastest way through the project is to do it right
If I ever see a "friction" on an Open Source project, my default assumption is that someone submitted some code, and it was rejected by the project. Further digging often reveals that the rejected code was either not compliant with the coding practices of the project, deviated from an agreed upon direction of the project, infringed in some way on someones IP, or had some other similar issue.
In some cases these led to schisms and two projects working on similar things.
Open Source the Evolutionary Play
Funny thing about that schism thing though: It is not a bad thing all the time. Sometimes the new project is better than the old one. There seems to be a sort of survival of the fittest / most useful aspect to things like that. It is like taking a bad thing like a disagreement and using it to power an evolutionary force for positive change.
In real life the group is always right, except when they aren't.
Vision is a hard thing to communicate, but creating a real working version of something based on the vision can be demonstrable, and can bring people over to a whole new way of doing things. See the open protocol move from Gopher to HTTP (kinda like open source in a way). I'll be honest. I didn't get it. I thought Gopher was all I would ever need for browsing Internet content. Hoo Boy.... is my face red! I can be taught though. I am writing this post with Firefox on Google Docs.
Open Source the Competitive Event
Often, neither project from the schism dies. It may not even have been a schism that created them both. Sometime a need is perceived by multiple people in different places at the same time, code is written and released nearly at the same time (parallel evolution if you will) and both solutions are good.
See KDE and Gnome for a way this can be good: two groups in a usually friendly competition to see who can develop the best GUI there is for Linux and other OS's. That may go something like: Gnome dislikes that KDE is written on a dual licensed, somewhat proprietary 'qt' toolkit from Trolltech, so they create GTK. The KDE project focuses on something else: say having better font management or prettier menus or better themes and then Gnome comes up with SLAB. OK. SLAB. Bad example. You probably get the idea. Trolltech changed their license because of this issue too. The point is both GUIs just get better and better over time, while at the same time retaining features that set them apart from each other and make them unique, useful, and interesting. As long as I can use Gnome apps under KDE and KDE apps under Gnome, i actually don't even care. But I am not a purist in this regard.
Open Source the Pride and the Ego
I know from working with people that have written Open Source applications that there is a unique pressure to it that does not exist in other, more traditional software development models. Other people will be seeing this code. Other programming professionals. People all around the world. The code that leaves your computer has to be worthy of being seen. Poor programming practices, lousy commenting and the like will end up with nothing but rejection and vilification from the community at large. (Actually, more often than not the criticism is gentle and constructive, and it just feels like someone called your baby ugly).
Even if the code does something useful, it will just feel bad when you see that post where someone said in the comment:
"Here is the new version of XYZmodule. Sorry it took so long. I had to go clean up a bunch of stuff in the original code."
If that is your code they just cleaned up, it just sometimes feels bad.
Open Source the Building Block
Another aspect related to several above is that Open Source projects tend to migrate towards modularity quite often. Projects may start out as monolithic code, but over time with things like:
Multiple people in multiple places working on them
Needing to check out certain bits and make changes
Not wanting to impact everyone and everything
etc.
There is a general subtle push towards writing better and better, more modular and more reusable code.
Part of this is probably the influence of UNIX. Much Open Source code originates in the Linux and FreeBSD ecosystems. At the core of UNIX is the idea of modular programs and pipes to connect them. LS commands feeding AWK or GREP and so on. Small code bits assembled in stacks to make new and unique and very useful things. That paradigm appears (to me) to be a strong influence on many open source projects. One project writes a device driver. And another and another. A project like MythTV picks up the device drivers and creates a DVR. It's not as easy as it could be to install, so a project like MythDora or KnoppMyth comes along to simplify it. Things like that.
Open Source and Collaboration
One of the private amusements (not so private now I guess...) I have is the idea that people will collaborate if you just buy the right tool. "If we just had a corporate standard..." it usually starts. It is a horse and cart problem though. People will never collaborate until there is a culture of collaboration.
With the 'right' tool in place, people can not collaborate much more expensively I guess. Read that fast ten times.
Open Source projects are by their very nature collaborative. There is no other way that they can survive. Projects that can not collaborate tend to die out, or create very small, very tiny things. That is not a bad thing. If all you need or want is a small thing, then a single person project or even one ruled by a tyrant might do OK. If the code produced is any good, it might even be picked up by other projects and used ala the building block thing above. But a big project: one like the Linux Kernel or OpenOffice has to be collaborative. It is the nature of the beast.
Open Source, the Journey
Open source is so many things. Ideas, concepts, culture, processes. The idea that it can be packed into an acronym or phrase, and that the acronym/phrase would have any meaning is ludicrous.
People do like to have labels for things though. It is also not possible for everyone to have deep understanding about everything. There are just too many things. You can talk about "Open Source" but that phrase is not automatically imbued with meaning until you know the entire context at hand.
One minor example of this: I was presenting about VM a while back at mainframe conference. A person in the presentation commented at the end that VM was not open source. I was confused till he pointed out that in my presentation I had used upper case out of habit to describe VM as "Open Source". Since IBM had the copywrite to the VM source, it was in fact not "Open Source" but only open source. He was not being pedantic. It is an important distinction. In a verbal conversation, unless I used 'air quotes', it is a distinction that would not be communicated by the phrase alone.
When BMC says it is hiring whurley to develop BMC's Open Source strategy, you have to understand that the single phrase can not even begin to encompass all whurley is here to do (whether he knows it or not. Evil laugh. He is not the only Evil Genius at work here....).
Since one can not boil the ocean (short of the Sun getting hotter and hotter as described above) I am sure he will have to focus. Pick out the big wins, and the easier targets. Culture change will be part and parcel of the mission. It will not be a light switch that gets flipped on, and one day everything is one way, and the next it will be another.
It will be a journey. The good news is, it will not be a lonely one.
