A pragmatic approach on open source software

October 27, 2010 | Miscellaneous

Using a product because you can view or modify the source code is not the point. It is like watching a movie that is split in 2 parts (or 2 disks) and you are in the beginning of the first one. Can you guess the ending yet? (Only if you are not watching it for the first time). Some people are cinephile and can really guess a lot still from the beginning. But such kind of people are not the majority.

The same applies when building a product. You need to be an experienced architect in order to choose the right tools from the beginning, trying to look as far as possible in the future to prevent drawbacks and bottlenecks.

There are really too many kinds of combinations:

From the above, if I run a company (ISV) or if I was a manager in a large organization doing enterprise software, I would only chose to work with people from the last 2 bullets. Do you know why? Well let me give you an example: What components do you need for an enterprise software using .NET?

Ask now a few which tools they would use for the above? You will get answers like “NHibernate for Data Access” and “Castle Windsor or StructureMap for DI”. These are the most popular not to say the de facto. So, why bother writing your own ORM since you can use NHibernate, why bother writing your own DI container since you can use an existing (and mature) one?

Let's be pragmatic.

Why we are getting paid? We are getting paid to deliver a responsive, scalable, working product. In order to achieve this we need to get equipped with the components mentioned above. Why not write our owns? Because (repeat) “we are getting paid to deliver a responsive, scalable, working product” we are not getting paid to build a specific reusable application block. But since we need to reuse as much code as possible we try to build around reusable application blocks. Why we are not using commercial (closed-source) products? Because if something fails in 02:00 AM we won't have access to the source code? This is a false statement, in 02:00 AM even if you have access to the source, you have no brain to study it. Actually you may, even, need some time to to build from source and start debuggin. 

Wake up at 02:00 AM and try to workaround on what I have previously discussed.

Let's say though, you build the source, find the bug and fix it. Then what? You would send a patch and hope that it will be out with the next release. If not, then you need to maintain your local copy and keep it sync with the current public stable release. 

What happens if you don't find the bug? Or don't know how to fix it? Or you can't get support in the forums? Do you know that there are companies out there selling commercial support for open-source software? Yes, you read it, commercial support for open-source software! What's the difference with using a commercial product now? The difference is the community :-) It's about the community of the open-source users, the culture, and knowledge sharing in forums, discussion groups and blogs. Yes, I buy this! But I don't buy commercial support for an open-source product. If I had to chose this way, I would prefer to change career.