It's 4 a.m., dark outside, the phone rings, your mobile goes off, you're in a convention hotel an ocean away from home in a different time zone. The server's fallen over, you need to bounce it remotely from a thousand miles away. You have to take the server down and bring it back up then restart the application. Good job the hotel has a connection and you have a signal.
Enterprise consolidation around a limited number of apps or one stack causes complications. It makes sense in terms of reducing support costs and ensuring that people are skilled up to the appropriate levels in the chosen software, yet this can stifle innovation. Instant access to new FOSS apps (without complex financial and procurement negotiations) stimulates new ideas, development opportunities and low/no cost prototyping for rapid application development.
Consider that prototype though and you may wish you'd never written it. The psychology works like this. Usually in the enterprise when Application X has fallen over, the business is fuming and the ether is thick with an email snowstorm, IT says, “We've got their professional services team on rolling calls looking at it”, the business relaxes and goes back to selling widgets.
Now think of it this way – you have a big idea, you write an app, you demo it to the business, they pilot it, they love it. That is, they love it until it falls over, then they fume, who are they going to call to fix it...? YOU – on tap.
So having people fully conversant with, trained and accredited on software X is a really good thing. You want to be innovative, the business wants you to solve a problem, you get creative. What happens when you've prototyped using Open Source and you haven't yet built a distinctive skill set in that software in the organisation? Suddenly the business – formerly grateful for your initiative, now has a gun to your head because they have become dependent on it, yet it is officially unsupported.
If you haven't built organisational expertise in FOSS apps prior to creating or in parallel with rapid prototyping of apps then this can mean that the individual that wrote it has has created a monster. He/she is the only person who can do 24/7/365 support – after all, by definition you are now 3rd /4th line support.
To avoid that 4 a.m. call let me recommend that we grow common expertise in working with leading apps. We use various tools – Special Interest Groups, Professional Communities, discussion threads etc. It's well worth surfacing the expertise around the organisation whether formally or informally – knowing who to turn to and what experience they have is vital, who can defrag those tables, who knows how v4 and v5 differ. And we need to develop and nurture the talent for this, so being able to identify contributors and sponsor them for certification is valuable.
In turn this support for non-supported applications and developers enhances flexibility and creativity, by allowing developers to follow their passion and innovate. So let a thousand flowers bloom – and feed them on Miracle-Gro rather than trampling them underfoot.