Flood of Competing Open Source Products Built by IT Vendors

My first programming language was c++.  A solid object oriented language still in use.  Could use different IDE's, different operating systems.  Quite nice.

Then I got into Visual Basic 4, 5, & 6.  Proprietary language, easy to get up to speed for simple to complex programs.  Had ability to call the registry, build COM component into a DLL pool and build Active-X.  Yet it was proprietary.  And tons of jobs back then.  Except they killed it off.  Gave us VisualBasic.net.  New language, kept the same name.  A real turn off for us classic VB enthusiasts.

The thing to note is the proprietary language, IDE and it only ran on Windows.

Then I got into Java a decade later.  Nice language, multiple IDE's, multiple platforms, operating systems, web and client side, connect to Mainframe COBOL copybooks program from the web.  You had the choice of IDE's which was nice.

But then they opened it up to Multiple Frameworks.  The pages seemed to jump around and I had much difficulty trying to figure out how to step through the code.  You could see the pages changing in the IDE, but it was confusing for me anyway.  I got out of Java and into Business Intelligence full time.

So we can see a mix of proprietary languages that run on proprietary operating systems using proprietary IDE's to free languages supported on multiple IDE's with community backed frameworks evolving over time for specific purposes and certain benefit's and weakness'.

Where are we now?  Open Source Community projects released for public consumption.  Major IT vendors contributing to the source code, and exposing that source code for public domain.  Not vendor specific, platform specific, operating system specific, nobody really owns it, except for Vendors that package and sell service and maintenance.

Let's say there's a need to do x.  Multiple vendors build their version internally, flush it out, then release to public.  So we have a market flooded with competing free open source products each claiming to be better than the others.  That's great for flexibility, perhaps it's diluting the quality, who knows.  And for developers, how can one stay up to date on all varieties and flavors.  And what are the downstream costs for early buy in and want to upgrade or switch later on.  And how do companies find talent to support and build apps when things are so diverse and ever changing.

Should we go back to the proprietary lock in when things were simpler?  I doubt it.  But the rapid pace of newness is a water hose very difficult to drink from.  And so it goes~!

No comments:

Post a Comment

Bloom Consulting Since Year 2000