Sam Minnée, Chief Executive Officer and co-founder of SilverStripe, has shaped the SilverStripe Suite and is part of its success story as an internationally respected open source CMS. Previously, Sam has posted about SilverStripe 3's new ORM.
When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.
If you haven’t heard of CCK or Views, the one line summary is this:
- CCK lets CMS users define new content types
- Views lets CMS users build new templates based on those new content types
(Disclaimer: I’m not a Drupal expert!)
The short answer is that we deliberately avoided building features like these into SilverStripe. We have taken a different approach when creating SilverStripe, and I’d like to explain why.
In essence, the appeal of these systems usually seems to be to avoid having to 'do more programming' in order to add new features to the site.
Reg Braithwaite coined an apt expression for this: Duck Programming (a play on the term Duck Typing). He defines Duck Programming as “any configuration that defines or controls mission-critical behaviour of a software system that is thought to be ‘not programming’ because it doesn’t appear to involve programmers, programming languages, or programming tools.”
The point is that putting a different face on programming doesn’t really stop it from being programming in practice. We had actually tried this approach in an earlier product (the never-open-sourced SilverStripe 1). What we found is that, although some simple systems can be set up with a model like that, most of the time people hit the edge of what can be provided.
Software developers have spent decades coming up with effective ways of describing application functionality that are both flexible and concise. The result of that effort are modern programming languages such as PHP and Ruby, and modern frameworks such as SilverStripe and Rails.
Furthermore, there are all kinds of things beyond the code that software developers have adopted to manage the risks involved; things like version control, automated testing, environment management, and deployment pipelines. Most duck programming systems ignore all of this.
Because of this, we have deliberately avoided building duck programming features into SilverStripe. However, that’s not to say we never will. If we were to build and maintain such a system, we’d want to see it support these things:
- Any custom functionality built using developer APIs built would need to be able to be extended by the duck programming system.
- Any custom functionality built in the duck programming system would need to be able to to be extended by using developer APIs.
- There would need to be a graceful hand-off between the base functionality that can be duck programmed and the extensions that are only possible with the developer API.
- All changes made by the duck programming system would be put through the same version control, test automation, and environment management controls as the rest of the code.
All of this is achievable, but it wouldn’t be a trivial progress, and we have been putting our development efforts into other areas, because frankly, we don’t see these features as a panacea.
One of the appealing things about duck programming systems - a commonly quoted reason for wanting this feature - is that you don't need programmers involved to keep growing the site. Often the word “programmers” is accompanied by a grimace, and a subsequent expansion on how frustrating developers are to work with. This saddens me more than it surprises. We believe keeping developers involved in the ongoing maintenance of an application is a good thing.
If you accept our assertion that programming code is the best way to reliably describe the functionality of an application, then perhaps you will agree that it is more useful to find better ways for the team to work with developers, rather than opting for a band-aid solution like duck programming.
To borrow the phrase of another open-source developer, SilverStripe is opinionated software: it is a CMS and Framework optimised for sites where business owners, developers, and designers work together constructively, rather than trying to avoid each other. This might not be precisely what you are looking for, and that’s fine too. It is a bad idea to try and make a product that is everything to everyone, and this is the niche we have chosen for SilverStripe.
But it begs the question, doesn't a collaborative approach to web development sound like a better way?