As I get older, some would say that I get more crusty [grin]. This may fall in that category, but my argument is that there is nothing wrong with simple and flexible. Put another way, “Round open source products do not fit in square commercial holes”. If you want to make the original round product square, add some extra bits, don’t chop bits off….
I have integrated with a number of commercialized open source projects over the course of my career and each time the people that are doing the commercialization take the original software and lock it down. I understand the tendency to want to make things less complicated, but in every case that is not what happened. The resultant product ended up more complicated and with less options, because things had to be done a specific way.
I know that I am being vague, but I don’t want to point fingers to make my point.
In a couple of cases I couldn’t understand the commercial software structure, so I referred to the open source documents in order to understand the architecture. When I turned back to the commercial software, I found that the clarity of the original design had been clouded by missing features and functionality.
Linux distributions are particularly bad for this. I have worked with several distributions that have been cut down to the point where commands like ‘ls’ don’t work. When I asked the developers why they cut so much out, they shrugged and said they only included what they needed. There were no limiting issues with respect to storage, it was just a case of less is easy to support. In this particular case, I was a product manager and was about to suggest an easy extension that would provide a customer with a feature that would close a sale.
I can’t count the number of times where optimization has lead to lost sales opportunities. In most of those cases the development teams justified their decisions by pointing to lack of feature specifications or use cases in the original design documents.
As a designer I am always trying to think about what Captain Kirk will ask me for next and I remove functionality only as an absolute last resort. If I am building on an open source product, I try to understand the original design concepts, before I attempt to extend them.
I firmly believe that simplicity is fundamental when it comes to understanding a problem or designing a product. Things can get complicated, but start from a well defined and partitioned simple foundation and don’t go pulling things out of that foundation or the whole project will fall in a screaming heap.
This is certainly one of the drawbacks of utilizing open source software. It may be free in most cases, but it more often than not creates more problems than it is “worth”. I too have been bitten by this more than once. Try upgrading a Linux-based system that is running an open source SaaS application, only to find that the OS has to be upgraded because it is no longer available/supported, which in turn has a new version of (in my case) Perl interpreter, which in turn requires changes to libraries that need to be recompiled, etc. etc.
The situation you aptly describe as “optimization” is more accurately referred to as “sub-optimization” and it often occurs in many aspects of business, e.g. business process improvement. Often a short-sighted decision that is initially thought to be beneficial ends up being a big move backwards. Simplicity and looking at the “big picture” always end up being the winners at the end of the day.
Another thought-provoking post. I enjoy reading all of your posts because they resonate so much with my day-to-day activities. Kudos!