Without dipping into some semi-evangelical hard selling intro, all I’ll say is, Open Source is the way ahead. It’s the future. It’s disruptive technology at it’s most disruptive and it’s the basis of some very innovative business models. However, there are notable weaknesses to Open Source, and one such weakness is to be found in the very thing that makes Open Source strong.
And that’s being open.
“Bloging software organisation WordPress has warned that hackers posted compromised versions of its open source software after breaking into one of the servers behind its website.”
Now, while WordPress aren’t up their with the likes of IBM or Microsoft, they are quite a major player in their field.
So the scope and scale for potential disruption is colossal.
Quite separate from the compromise, or from WordPress itself, what concerns me is the nature of the exploit and the kind of problems such a thing could well point towards in the coming years.
As software developers and ISVs move towards service-oriented business models, by making specific use of Open Source principles and practices, they open themselves up to some truly unique threats and challenges.
Whether financial institutions would embrace Open Source is a different matter, but I’ pretty sure the various of heads of major IT departments around the world will have read this news with a raised brow or two.
And such news will in all likelihood find its way into a Microsoft press release in the near future.
Squashing bugs just ain’t sexy, dude!
While I’m not going to make any sweeping, broad generalizations about developers – especially those associated with WordPress, because that wouldn’t be fair – what I will say is that people are people, and boring, non-sexy, non-trivial activities are usually the kind of activities that are performed with a heavy heart.
And that might be part of the problem. However, not knowing more about the incident in detail, I can only speculate.
This incident does very clearly illustrate a fundamental weakness of Open Source, which is ironically nothing to do with Open Source as a methodology, but more a function of best practice, procedure and discipline on the part of the developers affiliated with Open Source.
Again, I am not slighting these people. Stuff gets overlooked, and that was clearly the case here.
What can be done about this? More disciplined practices for sure, but for big ISVs, there’s going to be a very clear need to assign entire teams to validating code before any of it goes anywhere near the end user…