It appears from the lack of feedback that open system software participation or utilization is not much of an issue for this audience. We did have one response, however, from a reader having worked at a large company that had an open, free for all, acceptance of open software selection and implementation. This worked well for individual projects. It fell apart when multiple projects needed to be supported on shared servers.
I feel s similar pain simply using frameworks and toolsets from the Dot Net stack. I started an application as WebApi because it was an application only providing RESTful services. Then the customer felt it would be nice to have some administrative views into the performance of the service. So, I added in RAZOR templates.
One of the nice things about using templates is that it pulls in all the different libraries needed to make everything work. One of the not nice things is that if you have a single project sharing different templates, and those templates include other components, and those other components may be from the same library, but from a different version, you get some interesting behaviors, or at least a compile time warning that there is a conflicting version selection.
I guess the point to take away is that nothing comes for free. Single sourcing vendor solutions, such as those provided by Oracle, does not ameliorate conflicting assemblies or versions. While one approach is to take a heavy handed stand with a specific set of tools and versions, it can stifle solutions and restrict corporate resources in a negative manner. Neither is the option of open chaos an acceptable solution; it can have an even more negative impact on the company.
Where do we find a happy medium? Get into the conversation with your comments here, or by email to btaylor@sswug.org.
Cheers,
Ben