On a slightly related note, we're preparing an online course pitched entirely at setting up / using Wordpress in a museum context. I'll punt it here (if I'm allowed - I kinda lost track on the commercial rule..) when we're ready…
cheers
Mike
_____________________________
Mike Ellis
Thirty8 Digital: a small but perfectly formed digital agency: http://thirty8.co.uk
* My book: http://heritageweb.co.uk *
On 17 Oct 2013, at 09:53, "Bonewell, Perry" <[log in to unmask]> wrote:
>> Related to this, I'd be fascinated to hear of examples where organisations have not just used open source, but have contributed back to >the core technology in the form of modules/plugins/themes etc or even the underlying platform. I'd especially like to see examples >beyond the likes of 'install this plugin and you can put our collections on your blog' (although those are interesting too!)
>
> I'd be interested too James - I find it slightly frustrating that there isn't a strong (any?) museums strand to OS CMS development - apart from Omeka I guess. Time and again people complain that these systems don't fulfil some niche or other (image metadata quoted earlier in this discussion being an example) when they can be easily extended.
>
> Why aren't museums investing more in developing OS tools for platforms that everyone can use - and might help museums that don't have the budget to invest long term in something that is bespoke?
>
> I worry that when any public organisation invests in something licensed or proprietary it is a missed opportunity to share knowledge and best practice. And also the possibility that someone else might in turn improve those tools which they can then take advantage of. It's public money we're spending after all.
>
> I wrote a perhaps slightly naïve and idealistic post about this a while back: http://pointatthemoon.co.uk/2012/02/imagining-a-wordpress-museum-site/
>
> Sure, it is WordPress centric but the principles could be applied to any OS system. The point is, as a community, we don't appear to be creating an eco-system for ourselves to build the tools we (say that we) need.
>
> Perry
>
> -----Original Message-----
> From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of James Morley
> Sent: 17 October 2013 08:19
> To: [log in to unmask]
> Subject: Re: [MCG] Benefits of custom-built CMS vs adapting off-the-shelf - your experience?
>
> Great discussion and some really interesting, well-argued points.
>
> Related to this, I'd be fascinated to hear of examples where organisations have not just used open source, but have contributed back to the core technology in the form of modules/plugins/themes etc or even the underlying platform. I'd especially like to see examples beyond the likes of 'install this plugin and you can put our collections on your blog' (although those are interesting too!)
> ---
> James Morley
> www.jamesmorley.net / @jamesinealing
> www.whatsthatpicture.com / @PhotosOfThePast www.apennypermile.com / @APennyPerMile
>
>
> On Wed, Oct 16, 2013 at 9:55 PM, Nick Sharp <[log in to unmask]> wrote:
>> Thank you all so much for the incredibly helpful and insightful advice.
>> I'm overwhelmed by how supportive the MCG community is!
>>
>> What I think I've found is that it's not as cut-and-dried an issue as
>> I thought. Having been brought up very much in the Wordpress/Drupal
>> 'open source is good, proprietary bad' orthodoxy, I'm a bit thrown by
>> the possibility that another solution could fit our needs better.
>> We've been pleased with our agency partner so far, and they've done
>> some incredibly clever thinking about UX, future integration phases,
>> organisational design for the digital age etc. I don't anticipate us
>> not being in a medium-to-long term relationship with them. But I want
>> to make sure the technology choice is as future-proof as possible.
>> Which involves a bit of wishful crystal-ball gazing...
>>
>> I've been struck by the 'Open Source triangle' (developed by JP
>> Rangaswami
>> -
>> http://confusedofcalcutta.com/2007/08/04/build-versus-buy-versus-opens
>> ource / - the whole post is interesting) which suggests:
>>
>> For common problems use Opensource.
>> For rare problems use Buy.
>> For unique problems use Build.
>>
>>
>> I suppose we need to work out how unique (or even rare.) the things
>> we're trying to do really are, technically.
>>
>> Thanks again for all your help and advice - and do please let me know
>> if you have any further thoughts, it's been incredibly helpful.
>>
>> And if you're in London, do pop by and drop in for a coffee!
>>
>> Best wishes
>> Nick
>> @emuroad
>>
>>
>>
>>
>>
>> On 16/10/2013 18:27, "Janet Brunckhorst" <[log in to unmask]> wrote:
>>
>>> Hi Nick
>>>
>>> This is a tough choice, and one I had to make a couple of years back.
>>> I know a lot of people think I made a crazy decision, which is why I
>>> thought I'd share my perspective :)
>>>
>>> A little background: Prior to this role, I worked on a major site
>>> relaunch (Lonely Planet) that used heavily customized Drupal. The team
>>> was amazing, but the CMS was never quite what we needed (it was Drupal
>>> 5, though...).
>>> I
>>> then worked at a startup that had a custom-built Ruby CMS. I couldn't
>>> understand why they would build something custom, and asked the devs
>>> lots of questions about their decision. Their insights, and my
>>> previous experience, made me think that this was a far less clear-cut
>>> area than I had previously thought.
>>>
>>> We relaunched the Asian Art Museum website in February this year (with
>>> a partial launch in November 2012). We went with a custom Ruby CMS. We
>>> do not have an internal team (it's me, and I'm not a developer). I'm
>>> in San Francisco, so there are plenty of dev shops around (as there
>>> are in London). I deliberately set out to be technology agnostic
>>> because I wanted to focus on finding the right team to work with
>>> first. In my previous experience, picking the right team had turned
>>> out to be way more important than picking a specific technology
>>> solution (the right team should of course be able to make sound
>>> technology recommendations). I also wanted a local team, because of
>>> the nature of the project and the stakeholders involved. I still
>>> believe that these two criteria were critical for us.
>>>
>>> Your pros and cons are pretty much the same list I came up with. As we
>>> went through the decision-making process, I spoke to a bunch of people
>>> I'd worked with previously or met in the museum community, from Ruby
>>> devs to CIOs to Drupal zealots, to sense-check that we weren't missing
>>> some huge advantage or disadvantage either way. I came to the
>>> conclusion that off-the-shelf vs custom wasn't really the crucial
>>> choice for us; either one could do the job. Neither was going to be
>>> significantly cheaper for what we wanted. They both had advantages and
>>> disadvantages. So my initial criteria around people and their ability
>>> to work with us and deliver a great product remained front of mind. We
>>> had proposals from companies that worked with a variety of
>>> technologies; some who specialized, some who would build on a bunch of
>>> different platforms according to need. The one we chose is a Ruby
>>> shop. We could not be happier with them and the work they've done.
>>>
>>> We are incredibly happy with our CMS. We have just completed a Phase 3
>>> project with additional improvements. We work in Agile with our
>>> dev/design team, and maintain a backlog between projects to keep track
>>> of our desired improvements; this is working really well. We are
>>> considering implementing a maintenance contract/retainer to ensure
>>> that we have the ability to make minor changes, as our next major
>>> project will be several months away.
>>>
>>> You're right that we could not extend our system in-house. We couldn't
>>> really extend any system in-house, though; we don't have plans to
>>> build a dev team in the near future. So that was less of a
>>> consideration for us, and made it even more important that we be able
>>> to build partnerships that could last.
>>>
>>> OK, that was a really long way of saying: "people, process, technology
>>> - which would you choose?".
>>>
>>> Hope that helps - happy to chat more off-list if you want!
>>>
>>> cheers
>>> Janet
>>>
>>> Janet Brunckhorst
>>> Manager of Web and Digital Media
>>>
>>> Asian Art Museum
>>> 200 Larkin Street
>>> San Francisco, CA 94102
>>> 415.581.3667
>>> asianart.org
>>>
>>>
>>>
>>> From: Nick Sharp <[log in to unmask]>
>>> To: [log in to unmask]
>>> Date: 10/16/2013 04:02 AM
>>> Subject: [MCG] Benefits of custom-built CMS vs adapting
>>> off-the-shelf - your experience?
>>> Sent by: Museums Computer Group <[log in to unmask]>
>>>
>>>
>>>
>>> Hi MCGers,
>>>
>>> Firstly quickly wanted to introduce myself I started at the
>>> beginning of September as Head of Digital here at the Royal Academy.
>>> Do get in touch to say hello!
>>>
>>> I'm working on a website redevelopment project here, and I wanted to
>>> canvass opinion on our technology choice. Our technology partners are
>>> suggesting building a bespoke CMS (primarily using Ruby and other open
>>> source technologies), rather than adapting a CMS (like Drupal, for the
>>> sake of argument).
>>>
>>> I've worked with both solutions in the past, but I wondered if any
>>> MCGers had any thoughts based on their experience in this sector.
>>>
>>> My concern is that, when I've worked with a custom CMS before for
>>> example, GOV.UK it's involved a large internal development team,
>>> something we currently lack. I don't want to tie us into a
>>> relationship with one supplier (as with proprietary systems of old),
>>> but at the same time, assuming the language and technology are
>>> well-supported by the developer community, a custom CMS will offer us
>>> a lighter, more elegant solution.
>>>
>>> Does anyone have any experience of making similar choices, or how it
>>> has worked out for them? Realise this is quite a broad question and
>>> brings up loads of associated questions, both philosophical and
>>> practical. But would be interested in your thoughts.
>>>
>>> Couple of thoughts below:
>>>
>>> Benefits of a custom CMS
>>>
>>> * we can build exactly the right CMS for the RA, we don't have to bend
>>> an off the shelf product into shape
>>> * it will be faster, the database structure is optimised for the RA,
>>> an off the shelf CMS database is designed for flexibility
>>> * we can design a more dynamic system, unconstrained by the particular
>>> usage model an off the shelf CMS would bring
>>>
>>> Drawbacks of a custom CMS
>>>
>>> * extending the system will require more in depth knowledge, currently
>>> not existing in-house
>>> * Could tie the RA into a difficult/expensive issue if technology
>>> moves in a different direction
>>>
>>> Benefits of an off the shelf CMS
>>>
>>> * a community of developers exist that understand how to use it
>>> * can be extended easily to add functionality
>>> * includes robust code for handling classic content management tasks
>>> * powerful
>>>
>>> Drawbacks of an off the shelf CMS
>>>
>>> * upgrades to an of the shelf CMS could have unforeseen consequences
>>> for the system
>>> * an off the shelf CMS represents a retrospective view of the trend in
>>> content management. In contrast we are trying to build a future facing
>>> approach for the RA.
>>> * might cost money to buy a licence on a recurring basis
>>> * the CMS design might go out of date, or be superseded by better designs.
>>> * complex, lots of features are included which are not needed by the
>>> RA
>>> * Could prove expensive to build and customise for RA requirements
>>>
>>>
>>> Thanks!
>>>
>>> Nick Sharp @emuroad
>>>
>>> Head of Digital
>>>
>>> Royal Academy of Arts
>>> Burlington House
>>> Piccadilly
>>> London W1J 0BD
>>>
>>> 020 7300 5803 | 07718 236871
>>>
>>> www.royalacademy.org.uk <http://www.royalacademy.org.uk/>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The Royal Academy of Arts is a registered charity under Registered
>>> Charity Number 1125383 and is also registered as a company limited by
>>> guarantee in England and Wales under Company Number 6298947. Registered office:
>>> Burlington House, Piccadilly, London, W1J 0BD.
>>>
>>>
>>>
>>> The Royal Academy of Arts is a registered charity under Registered
>>> Charity Number 1125383 and is also registered as a company limited by
>>> guarantee in England and Wales under Company Number 6298947.
>>> Registered office:
>>> Burlington House, Piccadilly, London, W1J 0BD.
>>>
>>> ****************************************************************
>>> website: http://museumscomputergroup.org.uk/
>>> Twitter: http://www.twitter.com/ukmcg
>>> Facebook: http://www.facebook.com/museumscomputergroup
>>> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>>> ****************************************************************
>>>
>>>
>>>
>>> ****************************************************************
>>> website: http://museumscomputergroup.org.uk/
>>> Twitter: http://www.twitter.com/ukmcg
>>> Facebook: http://www.facebook.com/museumscomputergroup
>>> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>>> ****************************************************************
>>
>>
>> ****************************************************************
>> website: http://museumscomputergroup.org.uk/
>> Twitter: http://www.twitter.com/ukmcg
>> Facebook: http://www.facebook.com/museumscomputergroup
>> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>> ****************************************************************
>
> ****************************************************************
> website: http://museumscomputergroup.org.uk/
> Twitter: http://www.twitter.com/ukmcg
> Facebook: http://www.facebook.com/museumscomputergroup
> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
> ****************************************************************
>
>
> This e-mail and any attached files are confidential and may also be legally privileged. They are intended solely for the intended addressee. If you are not the addressee please e-mail it back to the sender and then immediately, permanently delete it. Do not read, print, re-transmit, store or act in reliance on it. This e-mail may be monitored by Bolton Council in accordance with current regulations.
>
>
> This footnote also confirms that this e-mail message has been swept for the presence of computer viruses currently known to Bolton Council. However, the recipient is responsible for virus-checking before opening this message and any attachment.
>
>
> Unless expressly stated to the contrary, any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Bolton Council.
>
>
> http://www.bolton.gov.uk
> ****************************************************************
> website: http://museumscomputergroup.org.uk/
> Twitter: http://www.twitter.com/ukmcg
> Facebook: http://www.facebook.com/museumscomputergroup
> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
> ****************************************************************
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|
