This work started with Seneca introducing Mozilla technology in their courses and soon Mozilla joined in, with key people giving lectures and making themselves available to the students. If you visit Seneca’s Mozilla IRC channel you will find a vibrant community where students, faculty staff, Mozilla staff and volunteers are busy discussing issues, working on projects and having fun.

This morning I spotted a tweet from Mark Surman, Mozilla Foundation’s executive director,  that linked to this excellent paper by Chris Tyler explaining how Seneca approach open source education.

OSS Watch, like Seneca and Mozilla are serious about open source education as the way to address the skills shortage. Along with the others members of the Teaching Open Source collaboration we are working to ensure students, educational institutions and industry alike acquire the open development skills that are so critical for much modern software development.

The article identifies Ken Saunders, a 41-year-old, legally blind volunteer for Mozilla as a prime example of the kind of third party contributions that are key to the success of open development projects:

Saunders is among hundreds of people who donate time and skills to Mozilla, the Mountain View (Calif.) company that releases Firefox and other open-source software. Even as Mozilla’s internal staff has grown to 250, from 15 in 2005, an army of volunteers still contributes about 40% of the company’s work, which ranges from tweaks to the programming code to designing the Firefox logo.

Innovation in open development can happen within the core project team, but it can also happen at the edges, where people with different objectives and interests see value in the projects outputs. According to the Business Week article Mike Beltzner, who runs the Firefox project, says that open development projects need to “allow people to innovate and to explore and [give them] the freedom to do what they want along those edges—that’s where innovation tends to happen in startling and unexpected ways.”

The article also discusses some less successful attempts at open development, highlighting some of the good and bad approaches to rewarding and recognising volunteer contributions. A recent case study on TexGen, published by OSS Watch, illustrates how the open development model can be used to apply to even the smallest niche area project.

Collaboration is the key

OSS Watch have been acutely aware for some time that the “standard” approach to software sustainability in our sector is to “throw more money at it”. Indeed, most of the bids into this call, that we are aware of, take this approach. At OSS Watch we take a longer term view. We believe that sustainability is about reducing long term cost through collaborative development, this requires a short-medium term investment in developing collobarative software development skills. Unfortunately, our sector is more accustomed to competition for grants than to collaboration for value for money.

Evidence of this can be seen in the OSS Watch experience during the writing the our EPSRC bids. We were approached by a number of people who refused to allow us to talk to others about their plans, a ludicrous situation since some of the gaps in experience in one proposal could be closed by bringing in another member of our network. In other cases we invited representatives of potentially competing bids to view and discuss our own bid in order to find points of collaboration. Some joined our open mailing list  and viewed our draft proposal in the wiki but not once did they contribute, they didn’t even acknowledge our invite. In other words they wanted to take, but not to give.

The end result of this competition is, in this case, a number of less than ideal bids. This prompted OSS Watch to sumbit a bid that explicitly called for the EPSRC to match our own bid with another with, in the funders eyes, a suitable domain specific expertise. Assuming that our bid is seen as valuable in itself we look forward to sharing our expertise with one or more of the other bid teams.

How do we collaborate?

It is our belief that to create sustainable software that survives between one development team (i.e. grant) and the next (i.e. another grant) we need to change this culture of competition into one of collaboration. In the non-academic sectors there are significant examples of this working on both large and small scales.

The problem with this approach is that project team currently expect their own chances of survival to be dependant on their “ownership” of the outputs and knowledge acquired during the first grant. Indeed OSS Watch are an example of this. As OSS Watch manager I am responsible for ensuring we have enough grant funding for over five full time staff. If I encourage others to enter our space am I putting my team at risk?

I don’t beleive so, my team have a very specific set of experiences and skills. Collectively we cover most aspects of open source software development. Our network reaches far and wide into the academic and non-acadmic open source communities, but we are not omnipresent. By being clear about our specialisms and recognising other groups expertise we should be able to increase the amount of grant money we recieve as we will get access to more varied pots through our cooperation. What the sector needs to realise and accept is that by being the expert one will be invited to participate in more projects not compete for less.

Whilst OSS Watch’s experience in this EPSRC bid would seem to simultaneously support and undermine this argument, it is our belief that in the long run cooperation is where value and sustainbility lies. There  are examples of this happening with niche software produced in the acadmic sector too. For example TexGen, a project at University of Nottingham has recieved significant additional funding as a direct result of the openness of their software outputs.

Sucessful collaboration means fully open collaboration

Unfortunately, TexGen is the exception rather than the rule. Even where collaboration is the goal, our sector still tends to artificially limit membership of the community to those who are funded. This can be seen in the Community Source model, popular in large US projects which excludes some parties from participation and therefore limits the sharing of both costs and rewards to a smaller group than is necessary.

The community source model aims to add a level of control to open development projects that it is believed does not exist in true open source. However, I would argue that this is a lack of understanding of the open development model rather than fact.

My own experience shows me that there are decision making models in open development that allow for the level of central planning and control needed in major projects whilst still ensuring the doors are open to anyone who wishes to contribute in a sensible and construcitve way. Indeed, if this were not the case then open source, and sustainable, products such as Eclipse, which is found at the heart of a large number of varied third party tools, would not exist.

In order to demonstrate this to be the case OSS Watch have been working with some experienced community source practioners in the Matterhorn Project. Together we have drawn up a governance model for this new project which appears to satisfy the control concerns of the funders whilst also satsifying OSS Watch’s concerns about keeping the commuity open.

At first glance this model may seem somewhat heavyweight for a smaller project. Therefore, OSS Watch have also worked with other parties to develop a much lighter touch governance model suitable for “rapid innovation” projects that are funded for just six months.

Those of you who read these models will realise that they are essentially the same model, it’s just that one defines more formal roles than the other since it has more initial stakeholders. This means that should the rapid innovation project be succesful it’s model can grow to accomodate a growing, and as yet unknown, community. It is this growth that is the start of sustainability through a collaborative development model.

The practice of open development

Now that OSS Watch have started to show that closed communities are not required, the next step is to encourage people to develop their software in such a way as to ensure non-community members are empowered to participate. It is these third party contributions that spread the cost of development across multuple financial pots and thus reduces centralised risk.

We recognise that policy is all very well but it is practice that matters. The adoption of open development practice requires a significant cultural change, but this is a change that our research shows is desired byenough practitioners to make it viable.

OSS Watch argues that funding projects to experiement with software ideas and then spending more money to “harden” the few that have promise is wasteful. We believe all software should be developed openly from the outset. By doing this the cost of sustaining software that succesfuly meets user needs is decreased since initial outputs, of all kinds, are reusable. Where software does not meet user need, as can often be the case in research software development,  the increased level of collaboration and awarenees within the community serves to increase the chances of success in future projects. This is because the community is sharing not only the “hardened” successes, but also the lessons learnt in other projects.

The Pan-European Workshop completed the launch week activities at Research In Motion’s Slough Offices and shared the proceedings with Raising The Floor an initiative by Gregg Vanderheiden and Jim Fruchterman to bring together all parties working on web accessibility, again using open practices. Greg has been involved in accessibility for many years and in his Introduction, Peter Korn, technical lead on ÆGIS sited Greg as his primary mentor. Peter in turn has been very active in open accessibility, especially the GNOME desktop which is used in Linux (e.g Ubuntu) and Sun’s Solaris. Peter along with Will Walker has taken a key role in orchestrating the  resources of their employer Sun to bear on making GNOME a focus of much open accessibility work, including infrastructure, the Orca screen reader, GOK on screen keyboard and collaboration with the Firefox web browser accessibility team.

In addition to hearing more about ÆGIS, the workshop offered the opportunity to catch up with some of the collaborators from the Ace Centre, OATSoft.org, aIDEAS & Mozilla as well as being something of a ‘tweatup’ for those who follow each other on Twitter, including Henni of Opera, Steve Faulkener and Gez Lemon of TPG and Davis Sloan of the University of Dundee. There was woefully little time to chat and I completely missed David Banes of AbilityNet and David McKay of Inference Labs, Cambridge (Dasher is an alternative text input program). I did finally meet Jutta Treviranus, director of ATRC at University of Toronto. Jutta is the boss of long term open accessibility developer David Bolter (e.g. GOK, dojo, ARIA), and we also heard the news that David is taking a years break from ATRC to work on Mozilla core accessibility with Maroc and Surkov.

Due to my failure to understand the scale of the map I arrived after the start having wondered up and down the batch road. The first few talks by M Gonzalez-Sancho (EU Commision ICT for inclusion, information and media Directorate General) and E Bekiarias (CERTH-HIT) provided high level views of the EU’s inclusion policies and AEGIS (£12.6M funding) as well as feedback from the previous days user forum.

Peter Korn then gave a technical overview with demos of existing applications including old friends such as the accessibility APIs, GOK, Orca+eSpeak, Dasher and Accerciser. In addition Peter showed an as yet unreleased simulator of visual impairments such as macular degeneration.

Dr Bekiarias then presented the AEGIS use cases which appear to present a reasonably representative and useful range. I was pleased to see symbol support in OpenOffice.org along with synthetic voices. As Simon Judge pointed out the desktop had little for AAC and switch users but  there is more on the mobile platform.

After an all too brief lunch, Dr C Galinski (InfoTerm) gave a presentation on structured content standards. This was followed by a very effective talk by Greg on accessibility overall and Raising the Floor. He made the point that what we do determines if ICT is a blessing or a curse to many users. He provided a clear analysis of the ways of providing accessibility (adjust interface, provide alternative interface, select alternative or download new interface on demand) and asserted that the accessibility API’s are the only real chance for an affordable and lasting strategies for flexible interface options (and I agree). He also considered reducing cost to users and the part OSS plays, seeing this as enabling more direct paths for the transfer of research and allowing the public coverage of costs other than licences. he also suggested we might like to consider free public access (cf public/private schools) and the need to fund more than research - e.g hardening, awareness, support.

Before the panel discussion Peter announced the Open Accessibility Everywhere Group. The desire to bring together all interested parties including developers, researchers and users and so facilitate exchange of ideas it echos the original motivations that underly Oatsoft.org and later Project:Possibility. While Oatsoft’s funding was only for an initial evaluation phase we can hope that OAEG will succesfully fill this important community role and so help us push the open accessibility envelope. There is an overlap here with Raising the floor that will need to be worked out, though AEGIS adds desktop and mobile accessibility to RtF’s focus on web accessibility.

I was pleased to see a place for the open accessibility projects I have been personally active in. In addition to key projects such as Mozilla, GNOME and NVDA I saw some potential for those I have been closely involved in as a developer; Simon Judge thought Maavis has something to offer in many use cases, and the straight-street.com open symbol set has much to offer. Jambu may also be useful as a starting point for some work. I’m not sure about PowerTalk as it relies on MS technologies but at least that is now included in the EduApps USB stick collection. Greg again mentioned his interest in OATSoft.org as providing the master list of projects, though the announcement of the OAEG seem to indicate it would be providing similar functionality after all.

So all-in-all a useful workshop but perhaps too many presentations with too wide a scope; I would have liked more networking time. ÆGIS is an exciting project and a serious opportunity for the benefits of open accessibility to be realised by users and developers alike. There is a lot to be done and good management will be need to ensure it delivers, but building on open development gives it a very good foundation for success. I’m looking forward to being involved as well as watching what happens.

I’m greatful to Ross Gardler (OSS Watch manager) for being so supportive of open accessibility and providing me opportunities to make it part of OSS Watch’s portfolio of experience. My first project was AccessApps and we spent Tuesday in a highly constructive consultation with the Maavis project, working out ways forward by embracing open development.

That reminds me I have an article on open accessibility to take though OSS Watch’s thorough quality control process.

If, as a consequence of a court judgment or allegation of patent infringement or

for any other reason (not limited to patent issues), conditions are imposed on

you (whether by court order, agreement or otherwise)that contradict the

conditions of this License, they do not excuse you from the conditions of this

License. If you cannot distribute so as to satisfy simultaneously your obligations

under this License and any other pertinent obligations, then as a consequence you

may not distribute the Library at all.  For example, if a patent license would

not permit royalty-free redistribution of the Library by all those who receive copies

directly or indirectly through you, then the only way you could satisfy both it

and this License would be to refrain entirely from distribution of the Library.

This clause is generally understood to mean that paying for patent licences to distribute LGPLv2.1-licensed code is impossible; once you pay for the licence you lose your right to distribute, so it’s never worth doing (and this in turn acts as a deterrent to patent owners looking to get per-copy royalties on LGPLv2.1- and GPLv2-licensed software - even if you win the case against the distributor, you kill the product and will get no royalties going forward). Nevertheless, Google’s lawyers seemed to have found a way through waters which had previously been thought unnavigable. As the argument on the thread continued, it emerged that Google’s approach had been to seek a patent licence for Chrome itself, not the ffmpeg library that was actually doing the video decoding. The LGPLv2.1 is designed to allow code it covers to co-exist in an uneasy peace with code covered by any other kind of licence, including patent licences. In this was free software libraries could be used with proprietary software in a way that would be impossible if they were covered by the full GPLv2. Google argued that as long as they never sought patent rights to use ffmpeg, no-one could accuse them of not passing on those rights to others in a way that ffmpeg’s licence mandated. All their permissions to use patents rested with Chrome itself - however it chose to do the decoding. 

 Now this is a sly move, and not one that has been attempted in as high-profile a piece of software as Chrome up to now. Will Google get away with it? Well that question really reduces to the question: Who might try to stop them? In this case Google Chrome is relying on licences from the MPEG-LA for the patents used to decode MPEG4 (and possibly theora if they want to rule out any future challenges from MPEG-LA on that score) and a software licence from the ffmpeg project. The likelihood is that Google have paid well for complete coverage from the MPEG-LA, and so a challenge from that quarter seems unlikely. What about the ffmpeg project?  Well they clearly explain that they have no specific knowledge of any patents infringed by distributing ffmpeg. Of course, everyone is aware that the project very likely infringes on many patents in the H.264 patent pool at the very least, but time and experience has taught programmers operating in patent-rich problem domains to never read the relevant patents. It only increases the likelihood that you will infringe upon them and increase the damages if it can be shown that you knowingly infringed. What this means for ffmpeg is that it would be very difficult for them to argue that Google is not in compliance with the LGPLv2.1 for ffmpeg because they have licensed some patents ostensibly for use in Chrome. To do so they would have to explain exactly which of the patents licensed were in reality embodied in ffmpeg, and would therefore trigger Google’s responsibilities inder the LGPLv2.1. This could be seen as an unwise move for ffmpeg. With neither the MPEG-LA or ffmpeg likely to question Google’s actions, it seems likely they will get no substantial challenge to their actions. 

How to invigorate your project with open development: Using an OSI approved open source licence on your project artefacts and putting them on a public server is one thing but how do you nurture a lively community that ensures your project continues to develop and becomes self sustaining?  Open development is the lifeblood of successful open source projects but how does it work, what tools and process make is successful? How does it mesh with the project life cycle and at what stage should it be introduced?  This breakout will explore open development and how it can be applied to individual projects. Come along and share questions, suggestions and experiences from your own projects.

This was a deliberate ploy to concentrate everyone’s energy on understanding open development as opposed to open source, as I explained in both this session and another lead by Steve Brewer on ‘Accelerating the deployment and uptake of open source tools in e-Research’. Working for OSS Watch has help me clarify my understanding of a fundamental principle of open source projects. This is something that, having been active  in several open source projects, I rather take for granted, but that is often not immediately apparent to newcomers to the scene.  The Apache Software Foundation say it well in their policy statement of  ‘community over code’, and back in 1992 the IETF’s phrase ‘We believe in: rough consensus and running code’ puts community decision making first. Having worked with active open source projects such as Mozilla and GNOME it’s clear to me that nurturing a vibrant and diverse community is the vital ingredient for success and sustainability. In contrast there is often a focus of attention on licence issues by those new to open source, and while this is a key part of the picture, OSS Watch now also emphasise  ‘open development’ in order to restore balance. This also helps projects more clearly see why fundamentals such as encouraging participation through the use of well tested collaboration tools and having a clear governance model are critical for their long term health.

Accordingly I was keen to steer discussion towards the issues surrounding open development and how to achieve it, as well as providing recommendations and clearly indicating OSS Watch’s desire to work with projects, providing support from our collective experience.

During the 2 days I chatted with members of at least 4 mature e-Research projects, each at an intermediate stage of practising open development; OGSA-DAI, DIASER, ALADDIN and Portal Access Grid. I encouraged all to go a stage further towards fully embracing open development, so it is exciting to hear announcements from 2 of them that clearly indicate that they heeded some of our recommendations.

Damian Brasher’s DIASER was already practising many of the principles and has now followed our recommendation to make early decisions and design notes available as project memory as these were not originally discussed on the public discussion lists. This involved considerable work but the outcome is that anyone can now find this information archived on public list and can more easily evaluate the project.

OGSA-DAI started as a closed community project though it is now released under an open source licence. During the workshop Mario stated his desire for the project to practice open development as I described it.  Thus it was a pleasure to see an article by Mike Jackson in the June 09 edition of National e-Science Centre news stating they are commited to achieving it.

OGSA-DAI: from open source product to open source project

The OGSA-DAI project has been funded by EPSRC for an additional year, until April 2010. This funding will enable us to evolve OGSA-DAI from an open source product into an open source project.

An international community of users and developers has formed around OGSA-DAI, our unique open source product for access to and integration of distributed heterogeneous data resources. This includes projects and institutions in a myriad of fields including medical research, environmental science, geo-sciences, the arts and humanities and business.

Moving to an open source project will provide the community with a focal point for the evolution, development, use and support of OGSA-DAI and its related components, providing a means by which
members can develop and release their components alongside the core product. It will also provide an avenue to ensure the sustainability of their components. Over the next few months we will set in place the
governance and infrastructure of the OGSA-DAI open source project. This will be done in conjunction with key community members, and will draw upon the expertise of our OMII-UK partners in Manchester and
Southampton and in the Globus Alliance. We aim to roll out our open source project site in October.

Our move to an open source project contributes to OMII-UK’s vision to promote software sustainability, and will guarantee that the lifetime of the OGSA-DAI product will exist out with any single institution or
funding stream. In addition, we will continue to develop the product and engage with international standardisation activities:

[snip]

The OGSA-DAI project -which involves both EPCC and the National e-Science Centre- is funded by EPSRC through OMII-UK.

I’d like to congratulate both projects for taking these important steps toward open development and wish them every success. I’m sure the OSS Watch team will be most interested to hear how they progress, I know I am.

OSS Watch provide many articles about open source development including a guide to participating in an open source community and a review of one of the best books on the subject - Producing Open Source Software by Karl Fogel.

Elections for the European Parliament are scheduled for 2 June 2009, and this seems like an ideal opportunity to broach the subject of ICT policies and draw the attention of candidates to the issues surrounding choices by government and its administration concerning software and systems. Hopefully, this will at least raise the profile and gain better consideration of the underpinning issues and lead to wider adoption of Free and Open Source Software.

One initiative attempting to do this is the Free Software Pact (FSP) providing candidates with a method to inform the voting public that “they favour the development and use of Free Software, and will protect it from possible threatening EU legislation.”

As Chairman of the Open Source Consortium I was asked to help promote the FSP. Fundamentally I agree with the underlying objectives of the FSP but I am not sure that the approach to implementation is well thought through.

I am convinced that level playing fields coupled with open and transparent processes topped off with effective governance (easier said than done, of course) are all that Free Software needs for new installations and also to trickle through the arteries and capillaries of existing ICT deployments, eventually eliminating the externalities of proprietary software (largely summarisable as the deadweight costs arising from distortions in the market). I should add that this opinion is vendor neutral. I don’t care who it is or how Free Software is supplied.

If we are to achieve this nirvana we need to approach those we are seeking to influence in terms that are meaningful to them. This is not always easy but that is not an excuse not to try. And it may require several goes. Additionally if one is seeking to influence politicians or administrations is is easier to go with the grain of things than start again somewhere else.

With that in mind and prompted by the FSP, it seems right to put my drafting where my opinions were. Accordingly the OSC has created a draft form letter that hope as many people as possible will send it to the candidates in their constituency.

Dear…

Support Implementation of draft European Interoperability Framework V2 “EIF V2″

As you are a candidate in the forthcoming elections for the European Parliament I am writing to seek your support for a simple measure that will help citizens, businesses and European society.

Information and Communications Technology (ICT) has become a critical part of European infrastructure; a modern economy cannot function without it.

Optimal choices in ICT need a European policy on interoperability in ICT.

Interoperability means it does not matter how you mix and match the constituent parts of ICT, they will just work with each other without problems or issues. Such choice also means that users of your ICT systems (e.g., users of European or national government on-line services) do not have to make ICT choices based on your decisions, e.g., having to use a specific web browser (that itself may require a specific operating system).

Many European and national ICT systems have been implemented using software which does not enable easy interoperability, and instead creates an effect where it becomes easier, and some cases necessary, to choose more of the same supplier’s products, and harder to choose competing products.

Moreover, once governments or local administrations have decided to use software that does not enable easy interoperability, that choice imposes a requirement for the citizen or customer to choose the same software.

This network effect prevents choice, competition and limits opportunities to promote innovation outside vendor control, in the whole European arena for ICT.

To have agreed as policy the (draft) EIF V2 ( http://ec.europa.eu/idabc/en/document/7728) will halt and eventually reverse this situation.

This draft has been criticised by vendors currently benefiting from the current uneven playing field, but its adoption would not prevent any vendor, current or future, from supplying ICT to European or national governments.

The EIF is not considered to by all to be perfect, but getting it firmly “inside the tent” would enable it to be improved. I urge you to adopt or adapt this letter and write.

You can find your existing MEPs and candidates here.

Gerry Gavigan

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues),conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you,  the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

What this meant for Tomtom was that if they settled with Microsoft by - say - agreeing to pay them 1p for each copy of GNU/Linux they distributed, then they would in fact have invalidated their licence to distribute GNU/Linux at all. The GPL v2 insists that either the code it covers goes out with no additional encumbrances or it doe not go out at all. Now Microsoft is very aware of this provision. Their cross-licensing deal with Novell - detailed in an OSS Watch blog post here - was structured precisely so as to avoid this consequence. Many in the free and open source community feared that Tomtom would strike a similar deal with Microsoft, and fans of the lastest version of the GPL, v3, announced Microsoft’s actions in this case should act as a ‘wake-up call’ for developers to begin using the licence, as it includes changes designed to make such deals apply to the entire community if they exist at all. In the event, it would seem from the information we have that Tomtom has avoided emulating Novell, and has instead agreed to remove the FAT components from the version GNU/Linux they distribute on their devices within two years. This strongly indicates that Tomtom have accepted no licence from Microsoft relating to GNU/Linux itself, and Microsoft have agreed to just give them breathing space to remove allegedly infringing components, rather than insisting they take a licence.  So - a happy ending for all concerned? Not really. Microsoft must be pleased, as they have managed to give the appearance of winning a battle in which they were accusing GNU/Linux of infringing on their patents while not actually having to suffer examination of the validity of their patents in court. The free and open source software community is left wondering whether the FAT patents could be used against other distributors of GNU/Linux. Jim Zemlin, Executive Director of the Linux Foundation, seemed to be calling on developers to cut FAT implementations out of their software altogether. A couple of days ago, OIN announced the following:

…the patents used in the recent TomTom patent action have been posted by OIN for review and submission of prior art by the Linux community. Submissions may be made by visiting http://www.post-issue.org, clicking on the appropriate patent and selecting “Submit Prior Art”.

The Peer to Patent web site that OIN cite in that link is an initiative designed to allow the technology community at large to pool their collective expertise and thereby perhaps invalidate patents that ought not to have been granted. One way to invalidate a patent is to show that it was not innovative at the time the patent was applied for, that there was in the jargon ‘prior art’. The Peer to Patent site acts as a clearing-house for evidence of prior art on specific patents. In fact one of the FAT patents in question, 5,597,517,  has already been re-examined, provisionally invalidated, amended and then declared valid again after the Public Patent Foundation  or ‘PubPat’ (tagline: ‘representing the public’s interest in the patent system’) asked for the US Patent Office to take another look back in 2004. It will be interesting to see how far this pillorying of the Microsoft’s FAT patents will go towards their invalidation, given that this is their second re-examination.So another Microsoft patent case goes by and we are still no closer to knowing how justified Microsoft’s patent threats against Linux really are. Tomtom clearly found the effort involved in engineering out the FAT patents a worthwhile expense, but only tells us that it was likely to work out cheaper than the lawyer’s fees, and that Tomtom understandably had no interest in acting as a vanguard for the community on the issue. Perhaps the most reassuring thing for the community is that - so far - Microsoft has only claimed ownership of technologies which can be engineered out of GNU/Linux without breaking it.

1. too many different licenses makes it difficult for licensors to choose
   Some people use “license proliferation” to mean that there are just too many licenses and that someone needs to take steps to reduce the number. While this would be great, the OSI cannot make anyone use or not use a particular license. All we can do is educate and urge people to use a smaller subset of licenses. This comment generally came from individuals and small companies.
2. some licenses do not play well together
   Some people use “license proliferation” to refer to the fact that some open source licenses do not inter-operate well with other open source licenses. While we can urge people not to mix non-mixable licenses, we cannot keep people from doing so. This comment generally came from larger companies.
3. too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution
   This is related to the previous comment, but is somewhat different since it doesn’t complain about how the licenses interact, just that there are too many different individual licenses covering certain distributions and that it takes a lot of time to read and understand them all. This comment usually came from larger companies.

The OSI has, since the publication of this report, grouped licences as either “popular and widely used”, “special purpose”, “redundant”, “non-reusable”, “superseded” or “other”. OSS Watch encourage everyone to use one of the “popular and widely used” licences as these cover the major needs of most community and business models (the special purpose licences do have their place, but they are minority licences).

Today it was announced that the number of licences in the recommended group has been reduced from nine to eight since the Eclipse Foundation, along with IBM, have taken the steps necessary to supersede the Common Public License 1.0 (CPL) with the Eclipse Public License 1.0  (EPL).

Hurrah!!!

With simple things like microblogging we can point to Laconica with a resonable amount of comfort, but should we really be ignoring Open Micro Blogger simply because we have not used it ourselves, after all, it does focus on a stronger and more scalable back-end. What about the solutions we’ve not yet heard of? A quick search for “open source microblogging” turns up a fair number of projects that are worth a look, not to mention a promising looking article with the title “Top 10 open source microblogging services. Perhaps it’s not as simple as we first thought.

If it is this hard to identify “best of breed” open source solutions for something as simple as a microblogging service how hard would it be for a “Financial Management and Reporting” system? These are complex systems that need to be customised (or at least configured) for each use case.

Sometimes the enquirer pushes a little harder, often indicating that it should be possible to identify “best of breed” and that OSS Watch should do so. However, our position remains firm, we can’t evaluate everything out there, but we can help people identify and evalate the options in the context of their needs.

Lets consider the financial software market. I’ve used Compiere for Financial Management in the past. I was very pleased with it, but it’s not really a financial system, it is a Enterprise Resource Planning and Customer Relationship Management system that has some financial functionality.Would the CRM and ERP functionality help or hinder our requestor?

As well as Compiere I’ve used a pen and paper based double entry ledger system. It worked, requires minimal technical knowledge and is easy to source. Unfortunately it is error prone, requires considerable training and usually needs a real accountant to do magic periodically, magic you don’t want to be paying accountant hourly rates for when software can do it, perhaps GnuCash or jGnash would be a better option. However, these are targetted at personal finance not business (or academic) finance.

Then there are OpenER, SQL Ledger, TurboCash and all the others that are out there. These are all “best of breed” within their own domain. They all have strengths and weaknesses. The “best” depends entirely on whether their strengths are important to the user whilst their weaknesses remain hidden.

How did I come up with the (incomplete) list of financial tools above? Simple, I spent 7 minutes (yes I timed myself) searching the web and making snap decisions on the viability of the open source community built around the products. I rejected another four or five as they looked like unsustainable or immature projects. It is this skill that I think we can offer to people looking for open source solutions. The customer must then narrow down the choice by looking at the feature set of the product base. Once a short list is drawn up, OSS Watch can help evaluate the support options available for the project, that is we can help the customer decide if the open source solution fits their culture, e.g. is there a suitable commercial support offering or is there an active and supportive developer community that internal IT staff can engage with?.

Even when we explain this in some detail we find that some people still insist that we should be able to tell them what to buy. So, I’ll say, here and now, as loud and clearly as I can:

Procuring something without actually considering the functionality it will need is insane. It is almost certainly doomed to fail.

A software procurement specialist once told me “there is never enough time to do it right, but there is always enough time to do it twice”. I wish I’d listened to him then (I’ll not go into why, but involves lots of wasted money). At least I’m listening now. If you are ready to listen, you can stop reading and contact OSS Watch when you want us to help you evaluate some open source solutions.

For those still unconvinced let me try and illustrate the problem in a domain most of us know a little about.

Imagine you are buying a new car. All cars have the the same basic functionality and features, they go forwards and backwards, they have a steering wheel and they stop before hitting things (assuming the driver is alert enough to hit the brakes).

Despite all cars being the same (when considering base functionality) we don’t walk into a the local car dealership and say “what’s the best car” and immmediately buy the first thing that comes into their mind. Instead we find out which are the most suitable cars for our kind of use (driving to the shops, commuting, long distance travel, fun at the weekend etc.). We probably also read literature and reviews. Most of us would test drive a couple of our favourites. Eventually we would buy one.

It’s true that we rely on reviews and salespeople to help us narrow down the choice, but we have other methods for making the final selection, and, importantly, we would usually ask salespeople from each of the major manufacturers.

Anyone who watches car “review” programmes like Top Gear knows that even in the simple world of cars there is never a clear winner between two cars built for the same purpose. One will be better cruising on the motorway, the other may be better on country lanes. One will be cheaper to run, but the other mighter be cooler to look at, but beauty is in the eye of the beholder. It is not usually possible to say “this car is better than that car, regardless ofwho you are and what you are looking for”.

Sometimes it is possible to say “this car is just rubbish, it broke down 5 times in our road tests”, but once you get past obvious flaws that affect everyone you have to understand the drivers needs before saying “this car is the perfect car for you”. I’m 6′ 4″tall, I simply don’t fit comfortably into some cars, it doesn’t matter if everyone else in the world thinks it is the perfect car, for me it is rubbish.

[This is getting to be a long post so I won’t even start on considering maintanence options for the car once it is purchased.]

Since most people wouldn’t ask a really general question such as “what is the best car?”, why do people insist on asking OSS Watch things like “which is the best open source financial management software solution?”

OSS Watch can help you procure open source solutions, but we can’t tell you what to buy - sorry, it just is not that simple.