My post of yesterday drew a couple of interesting comments so far, one quite favorable, the other far more critical. As always I thank everyone for the their comments but I felt the critical response missed or misunderstood some of my key points. While I wanted to answer in a comment back, the length of the response, given our blogging tool, dictates a separate new post.
Now I probably shouldn't be surprised, but I always am, when we in the library software industry, with decades of experience in producing software for a specific market segment, try to share our experiences with those who are developing software under new models (community and open source in this case) for the same market and we find our concerns brushed aside or ignored or told our statements “don’t follow”. It reminds me of all those times my parents sat me down, told me that if I did “x” it was likely “y” would result. I nodded my head, went out the door, did exactly what they said not to do and then was surprised when “y’ resulted. I learned the lesson, but later than needed and in a much more difficult way than was necessary had I only been willing to listen and build on their experiences.
Let me be more specific. The reason I focused on community and open source is because it is clear, at least to me, that many of the OSS initiatives underway are ignoring key lessons that apply to all software (be it proprietary or open source). In the case of proprietary software, many of the answers have been worked out, but this isn’t yet the case for open or community source software. I think we’ll all agree that the motivating market forces are different between the two models – proprietary uses monetary means to prioritize and to decide, open source uses community, consensus and other motivators. Each has their advantages and disadvantages. However, despite those motivators many of the market behaviors will remain the same, no matter which (or both) of the software models is employed.
The point in saying that implementing one type of software over the other requires the same amount of staff is really entirely outside of my post. But let me respond anyway. First, I’d like to note that the amount of time required to install most products is very dependent upon the extent of the local site customizations. Most proprietary products can be installed and put into production reasonably quickly. However, most customers choose to extensively modify workflows, interfaces, etc. to accommodate local practices. I'll also note that when compared to OSS, most organizations supporting OSS tell anyone considering it: don’t select open source expecting cost savings, because that isn’t the primary benefit. Bottom line, installation time is more a function of local choice than a requirement of the type of software. I would also argue that while an institution may spend equal time implementing either type of software, the richness of the final solution may or may not be comparable. To complete the analysis, one needs to look at what does the final solution offer in totality? As I’ve said more than once about our Open Platform approach, which allows OSS extensions on top of our proprietary solutions: “Start higher, go farther.”
When we talk about redundant investments between vendors we need to remember again that there are different market variables that determine which solution(s) will prove viable in the market. With proprietary software we have a free and open market that will use monetary variables to decide among the competing solutions, which is the best to meet specific market needs. On the OSS side, the monetary force is currently judged (although clearly debatable) as a much smaller variable and as a result it responds to a different set of forces. But one of the key points my post was trying to make is that they are all rooted in addressing largely the same market needs that we in the proprietary software world must answer to, including: Does it provide a solution to the need? How many customers will use the product (community)? What are the costs to produce/maintain it? Will this result in good support being provided to the users at a reasonable cost?
The issues are the same, it’s just the mechanisms that provide the answers that vary and in the end the answers will share more than they differ, regardless of it being OSS or proprietary.
My post was not and is not designed to “divide” the world of software types. I’m quite proud of the fact that so much of my career has shown a steady path of trying to use and unify the best of both of these worlds. The post was written to extend that once again, by sharing experiences and knowledge I’ve gained in functioning in the shared and individual environments of proprietary and community/open source software. The question now is this: Will the OSS community learn these lessons the hard way or are they willing to build on our experiences?
