Archive for February, 2008

Lightweight project collaboration (participants wanted)

Published by Ross Gardler on February 29, 2008 in Development, Software and Community. 0 Comments

Earlier this week I met with various members of the SKUA and MyExperiment projects. I was aware that SKUA needed a social network tool for part of their work, and that MyExperiment was about to publish its API’s and make its source more open (it has always been open source, but is currently in a kind of stealth mode). I was also aware that this meeting had been organised so I decided to invite myself (well, I did ask permission, but it Tony Linde described it as a hijack!).

I wanted to tell both projects about Open Social and Shindig, the reference implementation of the Open Social standard. It was my belief that the needs of SKUA could be satisfied if MyExperiment became an Open Social container. This would reduce the need of SKUA developers to get involved with core development work in MyExperiement and would therefore make collaboration easier.  That is, SKUA functionality would be captured as Open Social gadgets in MyExperiment.

This kind of plugin architecture is a great way of ensuring collaboration is possible between projects. Functionality, that may not be critical to the core project can be added as an optional plugin. Thus the strategic objectives of the parent are not diverted by those of the second project.

Tony Linde blogged about the day (AM, PM). As his account shows, by the time I arrived at mid day the two projects had already identified a potential collaboration path. However, this was fairly heavyweight, requiring a tight coupling between the SKUA project and the MyExperiment project.  It is at this time that I introduced my ideas with respect to Open Social.

I felt I had the teams interest and so outlined another advantage of this approach using Simal, OSS Watch’s project registry tool.

Simal, has social network information contained within it (people connected by projects or standards adopted in those projects). I pointed out that this data could be exposed through, and complimented by Open Social gadgets from both the MyExperiment and SKUA projects. I also observed that Simal is not at all unusual in this within the JISC project space.

If there had been  any doubt about the Open Social approach this point seemed to clinch it. The MyExperiement techies immediately started coding.

Last night I succesfully embedded the MyExperiment TagCloud gadget into the SVN head version of Simal.

We are well on our way!

Does your project have any interest in working with Open Social? Would it be useful for you to consume social network data? Can you publish useful social network data?

Please join us on the OSS Watch Community Development list where we would be happy to help you explore and experiment with these ideas.

Risk Management in Open Source Procurement

Published by Ross Gardler on February 20, 2008 in Business and Strategy and Policy. 1 Comment

On the 18th of March we are running an event, Risk Management in Open Source Procurement, in association with the Open Source Consortium and Red Hat. This event provides an an opportunity for IT staff in UK HE and FE institutions to hear from and to talk directly with representatives of open source businesses in the UK, their academic customers and a number of specialist academic support organisations.

Why is such an event necessary?

In October 2007 JISC Inform ran an article on open source in HE and FE contained in that article you can read:

There is often a lack of understanding about how best to consider OSS as part of institutional IT procurement and development activities. Ross Gardler, manager of the HE and FE advisory service for open source software, believes such issues can be explained by difficulties surrounding evaluation techniques.

‘There often isn’t an established marketing department that will take you out for lunch and smooth talk you about the potential benefits, like there is with a commercial provider,’ he says.

and

An OSS Watch survey found that only 25 per cent of universities and colleges mention open source in their institutional policies, suggesting an important discrepancy between policy and practice. ‘Institutions need a policy that says they will evaluate open source solutions,’ says Gardler.

In a podcast that went along with the article we explore potential reasons for the lack of policies to consider open source. We discuss issues such as the lack of understanding about how open source is developed and supported by commercial providers and about how these commercial partners are only too happy to provide the kind of support found in any commercial software vendor.

It’s truly is a case of you get what you pay for. If you want to go the self or community support route open source allows you to do so. However, for institutional systems it is often necessary to reduce the risk by engaging with specialists to create and deploy the (nearest to perfect solution.

Ann Borda is quoted in the inform article as saying:

whatever final solution - open or closed source - is selected, it’s best to provide users with a choice of products. ‘It’s unlikely that a single set of software choices will meet everyone’s requirements, either technically or at the simple user-preference level,’ she says. ‘It’s highly desirable to allow users to choose their working preferences first and foremost.’

This is where open source has it’s strengths. You get a choice of experts to carry out this critical work, and you have the added security of being able to take ownership of whatever parts of the project you desire to.
What are OSS Watch doing to support the procurement of open source in HE and FE?

We provide one-to-one consultancy services to help people understand how to evaluate open source and open source providers using frameworks such as the Business Readiness Rating and the Open Source Maturity Model. These consultancies are great if you’ve already decided to evaluate an open source solution. But what if you are still unsure?

If you are are responsible for or influence software procurement we hope to see you at our Risk Management in Open Source Procurement event.

 

Can you build a viable community project in eighteen months?

Published by Ross Gardler on February 15, 2008 in Development, Software and Community. 0 Comments

The WebPA project is nearing the eighteen month mark. This is a significant point for OSS Watch because a question that is often asked of us is “can projects really create a viable community within 18 months” (18 months being the average length of JISC funded projects). Our response is that whilst a truly sustainable community would be difficult to create in that time it is certainly possible to build the relevant infrastructure and identify some key community players. In other words, one should be, at least, on the verge of creating a sustianable community after 18 months. However, we follow that up with an observation that this takes effort.

Most projects we consult with have not budgeted for that effort and without an example of a similar project successfully engaging with a community in the 18 months time limit it is hard for project managers to see the value of such activities.

So, does WebPA provide a case study to support our position?

They certainly put in the effort and are seeing some of the rewards, as described in an OSS Watch case study document, and the good news keeps coming.

The WebPA team recently blogged about the value of a community member who, although not directly involved with the ongoing development of the project, is helping generate interest in the project across the world. This recently resulted in use of the WebPA tool spreading into Australia. The very fact that there are international users helps to build community and thus the sustainability of the WebPA project, even if those users never contribute code.

Note that this is a result that did not require significant effort from the funded project team. Because WebPA have built the necessary community structures and models community members are starting to become self supporting. That is what we should be looking for in a project around eighteen months old.

The WebPA team continue to raise awareness of their project and their community. Recently they reported that they have been named as a finalist in the IMS Global Learning Impact Awards. They are also running events designed to increase the user base for their product by demonstrating it to interested parties.

OSS Watch are meeting with WebPA again soon. We will be discussing sustainability beyond the current JISC funding. When we originally met with the team they informed us that a key factor in their survival would be the creation of a viable community. I believe they are well on the way to achieving this and I look forward to exploring the myriad of options they now have available to them in moving into the next phase of project development.

Routes to sustainable open source

Published by Ross Gardler on February 1, 2008 in Business, Development, Strategy and Policy and Community. 0 Comments

A few days ago I agreed with Marc Fluery, observing that he knows “a thing or two about sustainable open source.” Unfortunately his latest post shows that he is yet to grasp that whilst he has learnt a great deal about one route to sustainable open source he still has a great deal to learn about others.

In this post Marc states that:

“the ultimate license scheme for OSS is still RHEL/Fedora: a proprietary distribution of OSS software.”

This is far too simplistic. What licence scheme is appropriate to your project is fully dependant on your sustainability plan. If you want to go down the support route the “proprietary distribution of OSS software” is certainly one route. It is the one that grabs the headlines with acquisitions like Red Hats buying JBoss (that’s where Marc earned his stripes) or Sun buying MySQL.

However, what if you don’t intend to make money from selling a proprietary version of the software? What is your objective is to reduce your internal costs? What if your objective is to have the most robust framework on which to build bespoke solutions for your customers? What if you don’t want to make money but drive standards adoption?

The figures speak for themselves (at least for OpenLogic in the states, I’m not aware of similar figures in the UK):

Apache, not the GPL, is most common license in packages used in enterprises today. 62% of the packages use Apache, 27% use some variant of GPL and 4% each use BSD, CPL, Eclipse, MPL and Perl licenses. Since packages may be released under two or more licenses, percentages total to more than 100%.

Read that again there is more than twice as much Apache licensed software in the enterprise as ther e is GPL licensed software. That’s alot of software to support, and you know what, people get paid to support and develop it. Some even build very successful businesses that are dependant on their use and support of that software.

Do you need evidence of successful business who use, support and invest in non-GPL code (as well as GPL code in some cases)?

Lets start with a pure play startup (there are many, I’ll pick one that is topical right now). Springsource is the company that creates and supports the Spring framework, one of the most popular Java/J2EE application frameworks. Spring is Apache 2 licenced. Springsource recently purchased Covalent a company who provide support for non-GPL software and which has “more than 50% of the Fortune 500 and more than 70% of the Fortune 100 companies” as their customers.

Need more evidence? How about a different sustainability model, one based on cost savings through collaborative development. For this one lets do a little research, go to the following website and search for the terms in brackets after the URL:

http://www.oracle.co.uk (apache eclipse)

http://www.sun.co.uk (apache)

http://www.ibm.co.uk (eclipse apache)

Whilst it is true you will not get rich by providing consultancy services to these big boys, you can be very sure that the projects they use, support and develop all benefit from the resources, experience and market expertise these players bring. The fact that the Apache Software Foundation is so successful proves this,. What other process can produce such a large body of high quality software with just a single paid staff member (and even that one staff does infrastructure support, not development).

I accept that most projects aren’t of interest to the big boys. But may well be of interest to other smaller players. People you can form strategic and collaborative partnerships with as part of an open development community. Such partnerships do not prevent you from making a profit if that’s your goal, but they do open up new avenues for sustainability.

Consider all options then make a decision

Marc, there are many more ways to reach sustainability and profitability in open source. Please, next time someone asks you “I am about to launch a project in open source, we have invested a good man year in developing it and I want to know what license I should use for the project”, do what OSS Watch do. That is, understand the objectives of the project and give guidance appropriate to the situation.

If you need real advice on what licence is best for your project OSS Watch provide a free (to UK HE and FE) non-advocacy consultancy service.