software development

Sigurd Magnusson sent us an email to let us know that "SilverStripe has now split its company and open source projects into two totally revamped and beautiful websites".  The two SilverStripe websites will of course have different purposes.

Head on over to the SilverStripe.com site if you want to know more about our company and the business side of things. But if you're looking for the SilverStripe community, developer documentation, or the roadmap for the future of the product, you're in the right place [SilverStripe.org].

Explanation for the split was given at SilverStripe.org stating that the changes were made to "make navigation and discovery easier" for SilverStripe's customers and developers.  However, I suspect the purpose of splitting the site had to also do with the fact that SilverStripe as a commercial entity needed to have its business side become less visible in its own open source project. 

SilverStripe's decision to separate the commercial side and the open source side of their business is a strategic business decision.  I have observed that it is very difficult for open source projects to flourish without a strong open source community supporting the project.  Most open source communities become quite distracted when commercial interests tries to circumvent control and direction away from the community.  By giving SilverStripe the open source community a chance to flourish more on its own via a community website, SilverStripe the company can spend more time focusing on the needs of their business customers at SilverStripe.com.  Strategic moves such as this usually result in a win-win situation for both parties involved.

Smashing Magazine has posted a couple articles to help web developers and designers with their Wordpress and Drupal sites.  Some great suggestions and resources are listed in these articles.

1. WordPress Developer’s Toolbox
2. Drupal Developer's Toolbox

Tim Wilson, the site editor for Dark Reading, recently posted an article about recent at the AARP.org website.  In the colorfully titled article, "Porn Operators Hijack Pages on AARP Website", Wilson interviews Jeremy Yoder of MX Logic about why AARP.org's site was vulnerable.  In brief, the explanation given is that the site deployed a number of Web 2.0 features including user profile submissions which the site didn't properly filter out JavaScript redirected code.  Yoder than explains that the site's security or lack of security was due to it using a custom or in-house built content management system.

The AARP site is particularly susceptible to this sort of multi-pronged attack because it appears to be driven by a home-grown content management system, Yoder says. "It appears to be a custom system that's missing some baseline-level security capabilities. This site is accepting JavaScript code submissions, which are something that most off-the-shelf content management systems would have no trouble blocking."

AARP may have fallen into the trap that snares many sites when they seek to add Web 2.0-type capabilities, Yoder explains. "They choose their content management system based on its features, without giving much thought to its security capabilities," he says. "That can be a big mistake, especially if you are a site with a lot of visibility that might make a good target, like AARP."

Organizations that seek to build collaborative capabilities into their Websites should consider using systems that have been vetted by others, rather than a custom system, Yoder advises. "An open source solution has the benefit of a community behind it," he says. "WordPress has absorbed a lot of attacks, but now it's a lot stronger because of it."

This article brings back a lot of memories on past discussions we have had here at CMS Report.  A couple years ago, I posted an article that focued on a SitePoint article titled, I Have Never Met a Boxed CMS I Like.  The SitePoint article argued that a custom CMS would be a better option due to the fact that boxed CMS, whether open source or propriety, are too generic to be of value.  I argued that boxed systems cost less in both money and time, yet offered you more features than a custom CMS could provide.  After my post, a number of people commented for and against boxed systems.  Ironically, no one really talked about whether custom or in-house CMS were less or more secure than boxed systems.

In the world of IT, two years can make quite a difference.  It was not long ago that most Web applications would promote their security as an added feature to their product.  However, I think as time has moved on we realize that a secure site is not a feature of a CMS, but a basic requirement of the application.  In this respect, I can't help but think Yoder is correct that boxed CMS, whether open source or I'll argue a well-supported propriety package, is likely to be more secure than a custom CMS.  I think Sepeck's comment still holds true to why an "out of the box" CMS is the way to go.

If you want to 'write your own' then you are going to want to be locking your customer into you as a solution. I have met more developers convinced that they knew more then 'those other guys' about 'everything important' that end up leaving the customer with a virtually unsupportable system or so completely reliant on them, that when they leave, the customer has to spend as much or more on fixing or upgrading their sites later.

The 'out of the box' systems exist to fill a need because no one person (or small team for that matter) can be an expert on everything (web, rss, mail, design, information architecture). No one person should be able to lock a customer into them as a solution. That doesn't build a healthy eco-system for their customers or themselves.

The more eyes you have on the code behind the CMS, the more likely there is for someone to catch a potential security vulnerability.  When someone does find a way to hack into your system, the more hands you have working on the code the quicker the issue will likely be resolved to provide a security patch.  It isn't always true that boxed systems are more secure than a custom in-house CMS, but I'll argue that the odds are in the favor of the boxed CMS.