Slashdot Mirror
Australian Government To Standardise On Drupal
angry tapir (1463043) writes "The Australian government is eyeing the introduction of a government-wide content-management system, with the preferred choice almost certain to be Drupal. Government documents indicate that part of the appeal is that Drupal modules can be easily shared between government agencies and with the public."
Working with drupal is a nightmare. Drupal 8 is looking much better but all below are just terrible to work with.
As opposed to what? WordPress? Joomla? Drupal does have a steeper learning curve than some of the other open source CMS's but it has more flexibility, and if you're going to standardize on one, that flexibility is important. I'm curious to know if you have a specific alternative in mind.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
Easy to learn (as long as you know programming) and ridiculously flexible and simple compared to Drupal, with the ability to scale up to more complex frameworks with apps. Pretty sure the Australian government is targeting this for more complex frameworks, instead of just blogs.
Django itself is more of an app development environment, although using it for blogging and such would be as simple as adding one of the existing blogging apps to it, or you could roll your own with a few lines of code.
The Django tutorial is great... so glad I found it after looking at Wordpress, Joomla, Drupal, and other less popular ones.
Disclaimer: Website developer that has used Drupal, Joomla and Wordpress, not liking any of them.
I find that Silverstripe to be a pretty neat CMS for developers and clients. Find it much easier to work with than the other major players like you listed.
The New Zealand Government actually use Silverstripe themselves and they seem to be pretty happy.
Seriously though, it is actually enjoyable to work with for the variety of projects I have used it for. In time like the others, it might reach a point that it is no longer fantastic to work with and at that point, I will find the next system to adopt.
Coding a custom CMS is a start. Programming web-based systems isn't that hard. I do it for a living, but I use Wordpress or Joomla when the customer wants it. Generally a custom CMS offers better flexibility - if you have a competent web staff that knows how to code, you can get something slick finished pretty quickly.
There's a lot of fear mongering when it comes to picking CMSes in the first place. Generally you will see people that aren't qualified to make decisions force technical staff members into a corner to "standardize" things, pissing everyone off equally. These types of decisions, in my opinion, should be left to the individual web teams that serve these separate units of government throughout the country. They have to use it every day - let them decide.
It doesn't sound like the Australian Government even knows what it needs a CMS for. At the end of the day, KISS is the best practice to follow. They're just webpages after all. You don't need a CMS that has 26,000 modules (point was made in the article) to plop up a website with a slideshow, a bunch of PDF files, an event listing, different pages full of text. You only need to determine what you want your website to do and let the technical staff make the best choice. One CMS to rule them all is quite stupid in this case, because they think they're solving a problem that doesn't really exist. They also think there will be some kind of magical collaboration that will save everyone money.
http://agov.com.au/features - Half of the features on this page are purely fluff, pointless, or outright misleading:
1.) Reponsive design - Responsive design is tied to the template and CSS - not the fucking CMS. ... image sliders. Really now? This is a reason? Every Australian Government website must have this eh?
2.) Event management - every CMS out there features some kind of event management plugin, or you can just code one yourself. This isn't a good reason to "standardize" on. Again, let the web team working on the site pick the best option.
3.) Feature carousel - They're
4.) Rich content editing - Good, finally they found one reason to standardize their CMS onto every agency - because this is such a huge problem with CMSes - wait, what? No, it's not.
You know, there's more to this than the stuff I managed to quickly slap together at 3:30 AM.
My viewpoint is the following:
Making blanket assumptions on how things are used and forcing decisions across an entire Government will only lead to unhappy workers, stifling of innovation, and harm to other great CMSes and developers out there.
That said, if every agency felt that Drupal was their best option... so be it.
3.) Feature carousel - They're ... image sliders. Really now? This is a reason? Every Australian Government website must have this eh?
Yeah, I know what you mean.
Should I use a carousel?
What's wrong with Drupal? It's modular, very flexible, free, secure, and has been demonstrated to be good enough by other major organisations (ie, the Whitehouse, and Australia is essentially America's lapdog these days).
It's not easy to set up, but, that doesn't make it a poor choice, and what other alternative can you suggest which is proven to be secure, is flexible, modular and has a huge community base?
I hate our government for so many things, but, it's very easy to implement a powerful search engine in Drupal, and there are so many modules available that its a good choice for projects designed to last well into the future.
Also, one of my mates found a serious backdoor in a CMS system used often in Europe (and it was open source). So, since the Whitehorse has likely done some auditing of the Drupal code, it makes sense for the AU government to build on top of their work/testing.
4.) Rich content editing - Good, finally they found one reason to standardize their CMS onto every agency - because this is such a huge problem with CMSes - wait, what? No, it's not.
As far as I'm aware, all available editors are based on contenteditable functionality, which has been bug-ridden for years and simply was not designed to offer a rich content editing experience to the end user of a CMS. Yes, this is a huge problem with CMSes, including Drupal. For this reason, this is not fluff, pointless of misleading, it is an outright lie.
0x or or snor perron?!
It's simple. Many cheap hosting providers only permit LAMP stacks and won't have anything to do with a long running Python process associated with their web server. That creates an ecosystem where better solutions can't compete against the PHP masses.
I am becoming gerund, destroyer of verbs.
Coding a custom CMS is a start.
Why does everyone want everyone to reinvent the wheel? It's cheaper to do it this way. Drupal mostly works. If you can get 99% of the functionality you need out of the box, why not use it?
It doesn't sound like the Australian Government even knows what it needs a CMS for.
Presumably, to make it easier for departments to maintain content. That's the usual reason. It's a pretty good one.
That said, if every agency felt that Drupal was their best option... so be it.
Right, let every agency decide, and/or wait for consensus. What could possibly go wrong?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Generally a custom CMS offers better flexibility - if you have a competent web staff that knows how to code, you can get something slick finished pretty quickly.
True. But where I work, we plan for everything. Like upper management firing most of our "Competent web staff" Who's going to support your custom code then? If you're using an industry standard, it may not be as flexible but if the shit hits the fan at least you can pull in contractors and not have to rely on what would basically amount to the top tier of web developers out there as your only hiring resource. Use Joomla (or whatever) and you have an immediate pool of talent to hire from.
which consists of thousands of different modules
Fabulous! what every project wants - nay, needs - is to import THOUSANDS of different modules.
Yeah, and that's exactly how many modules are used in a typical Drupal site... why are people who truly know nothign about Drupal posting bad things about it..?
-Myke
There's plenty of PHP, ASP.NET, Django, Java, etc. developers out there. I would argue that there would be fewer developers for something like Joomla than it's parent programming language - PHP. This is because a Joomla developer needs to understand the idiosyncrasies of the CMS itself. They also need to understand how PHP works. So at the very least, they need to be able to code in PHP, otherwise you've just hired a crappy Joomla developer that probably Googles everything and copy and pastes stuff.
Coding a custom CMS or "reinventing the wheel" does have benefits. It provides security benefits by having less code, less eyeballs looking at the code, and alternative ways of configuration that may lead to better security (how it works with different server modules and such). It also allows for more rapid bug fixes for problems that arise, rather than waiting for a fix for 3 months after submitting it to a bug tracker.
You also have to think about how important the website is. Does this website provide a basic press release listing, PDF files, and a couple of pages? It probably doesn't need a massive CMS.
Let the web team decide what they would like to work with.
But there are so many features that customers eventually want that you end up reinventing lots of wheels hand-adding them along the way, eventually ending up with a Big Ball of Mud.
It may be good job security for the original coder, but for the organization it can be a bear to write up contracts and pay for new coding for various features that are add-ons with packaged CMS.
Maybe if OSS community offered kits that allowed easier add-ons to semi-customized CMS, we could approach the best of both. For example, settle on a generic data model so that add-ons can hook directly onto the data model. Custom programming can still be done using that data model.
Table-ized A.I.
You have to change nearly everything about how Drupal works to make it work well on a large site, or a large number of sites. So where is the "standard"? What it does with MySQL DB by default, as one example, is an absolute travesty. Then you run into, oh I can't build my massive site using nodes, it will blow up, so lets use templates, but now we have to mange templates, lets build something for that, oh now caching, how well does it deal with a big server farm, oh need patches and work on that too. Oh it isn't OOP so I have to do alot of extra work and process to keep the maintaince programmers from blowing everything up on multiple sites because they just know a little PHP and want to work in that all of the time vs the system you built. It is like so many other things, people spend tens of thousands of man hours on making it work, then say, Drupal is great! Just fucking amazes me. Of course Drupal isn't unique in that.
Coding a custom CMS is a start. Programming web-based systems isn't that hard. I do it for a living, but I use Wordpress or Joomla when the customer wants it.
I'm a consultant, and you're not thinking this through. You shouldn't start writing a new CMS from scratch whenever you start a new project. When I start a new project, say for a moderately complex web site, I go back to the beginning and design a new CPU. The new system that the CPU will fit into has to be designed, built and tested, and then a new OS written and debugged. Next a new communications protocol has to be designed, written and tested. Finally, a new set of applications written for the new OS, and then, finally, a web site.
This approach is the only reasonable way to turn a three month contract into a 15-year failed project. You've grasped the basic consulting creed of re-inventing the wheel at every opportunity, but you're not going far enough.
Work like no one is watching. Dance like you've never been hurt. Make love like you don't need the money.
Silverstripe is great, I've used it quite a bit and it does stand head & shoulders above the competition. But, possibly this is because it's written in PHP, it's dog-slow. Odd that the four comments above are all AC...