Re: An Open Letter to WordPress Foundation and Automattic

I don’t check into the various Advanced WordPress groups as often as I’d like; that’s something I’d like to change this year. As an early founder, I still perform various admin tasks and attend co-organizer meetings. But today AWP caught my full attention. When I checked into the AWP Facebook group I came across an interesting post titled An Open Letter to WordPress Foundation and Automattic. The author writes, “Because WordPress is the most popular CMS in existence, and because it has some vulnerabilities, then it is the perfect target for every idiot to try to hack it”. With WordPress, this was kinda resolved on day one: Open Source. Almost counter intuitive isn’t it? Security often implies privacy to keep prying eyes and the “bad guys” out. On the flip side, we’ve seen measures to take away some privacy to ensure a “safe flight”. Reflecting on decades under my belt as a MSDN solution provider; I remember facing a very similar argument this post makes: “Gee, ActiveX and Microsoft makes everything so easy. I can create solutions, make global fixes, and take over virtually any process on our client systems; I hope someone doesn’t use this for nefarious reasons”. On the rise to world domination, it certainly feels like security was an after thought (or intensional profit mountain for anti-malware partners) on Windows’ coveted component architecture: ActiveX.

Because WordPress is the most popular CMS in existence, and because it
has some vulnerabilities, then it is the perfect target for every idiot to try to hack it

ActiveX ushered in a huge third-party component marketplace not unlike WordPress’ own plugin directory. But along with third-party components came various levels of quality in code. Sometimes developers would come across memory leaks, incompatibilities, and buffer overruns (read: security vulnerabilities). Its early inclusion on Internet Explorer and Outlook claimed fame to some of the most virulent malware distribution. It even invoked a conference with the POTUS. Designers faced with such problems could contact the various third party authors. But little else could be done in the closed source architecture. Sometimes problems came from components made by Microsoft themselves, such as DAO (Data Access Objects) that leaked memory so bad that the only recourse was to schedule regular reboots. Depending on the magnitude of database work you required, it might have necessitated hourly reboots! Microsoft later re-arranged the letters (and the byte code) and rebranded DAO to ADO (Advanced Data Objects) but omitted my suggested tagline “now with less memory leaks”.

Gee, ActiveX and Microsoft makes everything so easy. I can create solutions, make global fixes, and take over virtually any process on our client’s systems; I hope someone doesn’t use this for nefarious reasons.

Flash forward today and we can see that the closed nature coupled with the ubiquitous use of ActiveX was its primary downfall that affected small and large corporations alike (i.e. Adobe Flash was the most distributed ActiveX component in Internet Explorer’s heyday). MicroHelp was another ginormous pre-millennium third party developer that suddenly and mysteriously disappeared, taking a chunk of source code with them. They left countless applications with no support and no traces of them could be found after closing their doors.

WordPress solved that problem on day one: Open Source.

So how does one address large popularity, standards, and security? WordPress solved that problem on day one: Open Source. By exposing as many eyes as interested into the very source code that makes up a WordPress based application we can mitigate Enterprise level failures. And unlike completely closed source components, code evolves faster and is less likely to suffer from ill effects of total abandonment. In addition, WordPress’ own directory includes behavior not unlike the Apple AppStore. It’s not perfect, but the initial screening does provide for some security checks and coding standards; a stark contrast to the wild west of ActiveX component delivery. One still has to pick and choose quality third party components wisely to avoid corrupt or vulnerable components; but the very nature of open source makes picking, choosing, and correcting for issues easier than ever before.

Leave a Reply

Your email address will not be published. Required fields are marked *