By nicole May 29, 2012
Uncategorized
open source, shibboleth, shibboleth consortium, standards

Today, the official begging letters asking for funding towards the Shibboleth Consortium started to trickle out. Full (probably unnecessary) disclosure – with one of my many different hats on I act as the Shibboleth Consortium Manager so this is not a disinterested post…but I have had many different and interesting conversations with people around the theme of why we are doing this that I thought would be generally interesting from a service modelling perspective.

Shibboleth is now a mature product, used in a significant number of organizations worldwide. As a mature product – this presents new challenges to the team. Firstly, it is seen as a Product and people expect a level of support – there are currently more than 1500 on the Shibboleth users list. It also means more maintenance requirements, more reliance on ensuring the standards space is up to scratch and more new feature demands. It also means that it is harder to justify the reliance on the current three funding partners. Overall, now is an appropriate time for Shibboleth to be reviewing its models.

So what are the issues?

1. Huh, money? But it’s free!

This is still strangely one of the first questions I get from people who probably should know better. Of course the software is freely available, but there is always a cost involved in creating it – the service of development (I’ve argued elsewhere that academic publishers could well adopt a similar model rather than paid for content). For most open source products this happens in three ways:

1. It’s done in spare time by completely dedicated developers. Whilst this is a fantastic way for innovative projects to start, it is difficult to make the decision to rely on such software in production environments. What happens when the enthusiasm runs thin?
2. Time donated by organisations. This has been the model that Shibboleth has predominantly operated on to-date. There are many challenges here – it can be difficult for developers to justify the use of their time in such a way, ‘big institutional projects’ come crushing down and divert the attention of developers and it can place the burden of financing developing unevenly on a handful of organisations. It is also very difficult to find the perfect balance of the talent you want at an organisation that is willing to release.
3. Funded developers. The majority of mainstream opensource efforts do rely on formal funding streams to keep their products usable and relevant. There are many models for this: foundations, paid for support, limited releases…but money is found somewhere to make for reliability and resilience.

Most organisations end up operating a hybrid model, and this is where we will be taking Shibboleth. Whilst asking for direct funds through membership and donations, we still have many developers donating code on their own time and contributions direct from organisations.

2. Why bother with support?

Providing support for users (as in people implementing the software, not lost students) is currently where the biggest percentage of developer time is spent…which causes much debate. We do have a good community of practise on the Shibboleth lists and several really good people in the community who will answer queries to the list, but the emphasis for support often falls back on the primary developer. As a project, we seem to be stuck between a rock and a hard place with some people calling for developers to stop providing any support and focus their attention completely on new features, and other people being, well quite rude, as we don’t offer a full service helpdesk. I’m not sure that people are fully aware that the Shibboleth project supports SEVEN different products in its current form – that’s an awful lot of stuff to simply coordinate and manage before we even get to support.

One solution to this would be to look at providing commercial grade support as a project, but this is something we have held back on. For a start, there are other companies out there already offering this and it would be rude to tread on their toes…although we might call on them for membership donations! Secondly this could cause a conflict with the focus of the project.

Personally I’m quite happy with the balance of support, maintenance and development we currently have but would love the opportunity to address more of the new features we get requests for. To do this, we really need new blood. To do this, we really need those membership fees.

3. Why bother, what will I get?

It’s true it can be a difficult case to sell. If you can pick up the software for free, then why bother offering money back to the project? It is worth reiterating again that we are all totally committed to keeping Shibboleth as an open source project. It’s also true you don’t get all that much for your membership beyond the right to vote for Board Members and listen in on consortium calls (although I am trying to convince people of the value of the Shibboleth Cuddly Griffy Toy for all new members). We’ve attempted to document the membership benefits here and I’ve created a slightly wacky pdf of where the money goes to.

Its probably easier with this project to try and frame it as what might you NOT get if funding dries up. We’ve had to issue a couple of security advisories this year, and the developers were extremely quick to react to these external dependencies. If the developers aren’t there, the patches won’t happen and we are in risk managment territory. It’s a sobering thought but risk management is a sensible approach for any institution using open source.

So those are some of the major issues we are discussing and will continue to discuss within the Consortium. I hope you find it generally useful and I really look forward to working with some of you as part of the Consortium membership in the year to come.