Thursday, April 24, 2008
Hypocritical perspectives on open source...
Awhile back, I asked if EMC employees are embarrassed that their employer uses but doesn't contribute to open source. Several bloggers inquired via comments as to whether my own employer does implying a level of being hypocritical...
Figured that this is a great opportunity to share some of my own personal thoughts regarding who should contribute to open source and more important who shouldn't. Consider the simple fact that most open source is not targeted at a particular industry vertical where many of my enterprisey friends spend most of their time learning their craft. The skills that it takes to be a successful developer to write a claims system is fundamentally different than being a successful developer who writes an open source portal or operating system. If you were to take Linus Torvalds and asked him to write a policy administration system, he could do it, but this is not within his zone of comfort. Likewise, I could find some really good developers in large enterprises who work on systems such as policy administration, but they may not have what it takes to write an OS kernel.
So, the first consideration regarding contribution is if you have the right skills which are deeper than just knowing a language. Of course this means that you have already abandoned the thought process that all Java developers are equal and haven't drinken the new FTE capacity planning kool-aid. A second consideration is that there are enough developers on the planet that can write code and the open source community doesn't need much more. What open source sorely needs is good documentation and therefore if an employee of an enterprise contributes to open source, they should not focus on source code but should focus on documentation. This could come in the form of writing books, magazine articles and sharing knowledge about a product in blogs and wikis. In many ways, the conversation is more important than the source code.
Taking this one step further, enterprises need to stop thinking about NDAs and to start thinking about ways to make their requirements more open. For example, if I am struggling with a problem space of making an ECM platform implement XACML and I provide several use cases, why should I only send it to the incumbent enterprise vendor? One take says that when enterprises articulate requirements, software vendors listen, NOT REALLY! What software vendors do listen to is how they compare to their competititors of which open source is one of them. Do you think that Documentum would allow for really cool features to exist in Nuxeo, Alfresco and other wonderful open source ECM platforms without them also having it? Sometimes the fastest path is to share requirements with your vendors competitors.
From a personal perspective, folks know that I have in the past contributed code to open source projects. I remember my first contribution in the security space where the code was functional and even secure, yet I remember receiving sarcastic comments via email from others saying that I code like I am an Enterprise Architect. Reality says, that the characteristics of what I consider good code as part of my day job, simply isn't good code by outside standards. Enterprises who don't appreciate the subtle difference can embarass themselves.
Code where their is collective ownership is most worthy of contribution. However, if your enterprise has outsourced software development to India where the vast majority of IT professionals are junior and lots of folks have stepped on it, then it may not make a good contribution candidate no matter how functional it may be.
In terms of contributing code under your employers name, I think I have an unpopular but accurate perspective. Reality says, that in order to write worthy code, it requires significant desk time. In today's meeting oriented culture, who has the time to have a continuous cohesive thought while at work. It has been eons since I have been able to keep a thought going uninterrupted for more than one hour while at work. Attempting to write worthy code in this scenario is futile. Reality states that the only time you can think cohesively is at home and therefore you are not on employer time...
| | View blog reactionsFigured that this is a great opportunity to share some of my own personal thoughts regarding who should contribute to open source and more important who shouldn't. Consider the simple fact that most open source is not targeted at a particular industry vertical where many of my enterprisey friends spend most of their time learning their craft. The skills that it takes to be a successful developer to write a claims system is fundamentally different than being a successful developer who writes an open source portal or operating system. If you were to take Linus Torvalds and asked him to write a policy administration system, he could do it, but this is not within his zone of comfort. Likewise, I could find some really good developers in large enterprises who work on systems such as policy administration, but they may not have what it takes to write an OS kernel.
So, the first consideration regarding contribution is if you have the right skills which are deeper than just knowing a language. Of course this means that you have already abandoned the thought process that all Java developers are equal and haven't drinken the new FTE capacity planning kool-aid. A second consideration is that there are enough developers on the planet that can write code and the open source community doesn't need much more. What open source sorely needs is good documentation and therefore if an employee of an enterprise contributes to open source, they should not focus on source code but should focus on documentation. This could come in the form of writing books, magazine articles and sharing knowledge about a product in blogs and wikis. In many ways, the conversation is more important than the source code.
Taking this one step further, enterprises need to stop thinking about NDAs and to start thinking about ways to make their requirements more open. For example, if I am struggling with a problem space of making an ECM platform implement XACML and I provide several use cases, why should I only send it to the incumbent enterprise vendor? One take says that when enterprises articulate requirements, software vendors listen, NOT REALLY! What software vendors do listen to is how they compare to their competititors of which open source is one of them. Do you think that Documentum would allow for really cool features to exist in Nuxeo, Alfresco and other wonderful open source ECM platforms without them also having it? Sometimes the fastest path is to share requirements with your vendors competitors.
From a personal perspective, folks know that I have in the past contributed code to open source projects. I remember my first contribution in the security space where the code was functional and even secure, yet I remember receiving sarcastic comments via email from others saying that I code like I am an Enterprise Architect. Reality says, that the characteristics of what I consider good code as part of my day job, simply isn't good code by outside standards. Enterprises who don't appreciate the subtle difference can embarass themselves.
Code where their is collective ownership is most worthy of contribution. However, if your enterprise has outsourced software development to India where the vast majority of IT professionals are junior and lots of folks have stepped on it, then it may not make a good contribution candidate no matter how functional it may be.
In terms of contributing code under your employers name, I think I have an unpopular but accurate perspective. Reality says, that in order to write worthy code, it requires significant desk time. In today's meeting oriented culture, who has the time to have a continuous cohesive thought while at work. It has been eons since I have been able to keep a thought going uninterrupted for more than one hour while at work. Attempting to write worthy code in this scenario is futile. Reality states that the only time you can think cohesively is at home and therefore you are not on employer time...
