Archive for the 'Discussion' Category

Treading the thin line between Free, Proprietary and Open Source Software

Published by Ross Gardler on January 4, 2010 in Business and Discussion. 4 Comments

For quite some time OSS Watch have been trying to put together an article examining Microsofts approach to open source. Today we welcomed the new year with the publication of “Microsoft: an end to open hostilities?“

This has been a very hard piece to write. We felt we needed to talk to as many people as possible, we needed to sift through  significant amounts of Fear Uncertainty and Doubt along with unnecessarily emotional responses.

Things weren’t made any easier by the fact that every time we felt ready to publish something else heppened that seemed to change the story somewhat and we had to return to our sources for more observations.

During our research for this article OSS Watch have been accused, by an OSI board observer and ASF Member, of being “surrogates” for Microsoft, whilst Tony Hey (Corporate Vice President of External Research, Microsoft) privately expressed concern that OSS Watch was “encouraging academics to use the GPL.” Simultaneously, various free software representatives have pointed out how “naive” they believed us to be by even considering the idea that Microsoft may have genuine intentions with respect to engaging with the free and open source community.

As a non-advocacy advisory service we tend to think that if all sides in a debate believe we are in the wrong, yet all are still talking to us, we are probably doing something right. Certainly none of them can claim us as their own.

Given all this input what did we conclude?

Well, as you would expect, the conclusion is far from clear. On the one side we have the Stallman’s (Free Software Foundation) view that “these free programs are meant specifically to prevent the world from freeing itself from non-free software”. On the other side we have Erenkrantz’s (The Apache Software Foundation) view that “every positive and constructive engagement Microsoft has with the open source community (and vice versa) … will continue to chip away at the old perceptions”.

Furthermore, whilst Microsoft may be making concessions to open source and are happy to play with open source when it suits their needs they are also willing to use other methods where it best suits their business. For example, on patents Darren Strange (Head of Open Source Engagement, Microsoft UK) says “Patents drive innovation and they drive openness actually.”

Our own conclusion is that “Microsoft is not simply an unchanging monolith.” The article demonstrates that things within Microsoft are changing. Naturally they are changing in ways that benefit Microsoft as a business, but the good news is that some of these changes also benefit the world of free and open source software.

Over the years I have often quoted Ghandi when looking at Microsoft and their relationship with Free and Open Source Software: “First they ignore you, then they ridicule you, then they fight you, then you win”. FOSS has not “won” yet, but the frontline is moving and it is open source software that is winning.

Mailing lists vs. forums

Published by Sander van der Waal on December 15, 2009 in Development, Discussion and Strategy and Policy. 4 Comments

On Monday the 9th of December we organised two simultaneous workshops on open development. One track was about open innovation whereas the other focused on the theme of building an engaged community around open source software projects. I gave a presentation on the latter track about my first experiences with an open source project and explained about the community tools that are essential for open development: a good homepage, a version control system, an issue tracker and mailing lists.

One question at the end of my session was about the mailing lists. I had explained that it is very important to have a publicly accessible mailing list that anybody can subscribe to and that you should ensure that all communication about the project is on the mailing list. The question was about why you should use mailing lists for this and not forums.
Continue reading ‘Mailing lists vs. forums’

Writing for the Web: a few tips

Published by Elizabeth Tatham on December 5, 2009 in Discussion and Event. 0 Comments

My worst nightmare at school was having to think of something for show and tell. I had the same feeling today, when I was asked to write a blog post as part of my new job as content editor for OSS Watch.

I have never written a blog before, and seldom read them, so I had a few questions for my colleagues. What shall I write about? Oh, anything really. Who am I writing for? Oh, anyone and everyone. Scary. All the more so because blogging is  personal and immediate – quite the opposite of the book publishing process I am used to, where the product is carefully crafted over several weeks or months and there’s a team to share the responsibility.

Luckily I went on a course yesterday, so at least I have something to write about. The course was called Writing for the Web, and I was keen to go on it because I wanted to know how the writing and editing processes for the Web differ from those in book publishing.

The course outline looked very promising: devising a strategy for your website; understanding how people read online; structuring your information; writing skills; managing your website; editing and proofreading; and creating reusable material. For me, it didn’t quite deliver on all fronts, but I did pick up some useful tips:

  • a website should not be seen as whole, and is non-linear, unlike most books
  • reading on screen is uncomfortable, so presentation is important (see http://webpagesthatsuck.com for examples of how not to do it)
  • consider the reader’s environment and accessibility issues
  • use storyboarding to plan the site, and to demonstrate layout of screens and navigation links
  • navigation reflects the relationship between information and also readers’ need to access it
  • people don’t read the text, they scan it, so make it scannable: use highlighted keywords, meaningful sub-headings and bulleted lists
  • keep headings short; the first two words are the most important
  • paragraphs should contain a maximum of two sentences
  • keep it short and simple (see http://www.plainenglish.co.uk/) and focus on the action
  • avoid ’speed bumps’: inconsistent use of terms, jargon, slang, non-descriptive headings, marketing hype

All in all, it was a useful day away from the office. I will now be able to look at our website in a new light, and think about how we could apply some of these principles to improve it, and the documents we write for it, for our readers. Pity we didn’t cover blogging.

More on video interviews at ApacheCon

Published by Gabriel Hanganu on November 11, 2009 in Community, Development, Discussion and Event. 0 Comments

In this video fragment Bertrand Delacretaz, member of the ASF’s Community Development Project Management Committee talks about the importance of knowing the qualities of the individuals forming an incipient developer community. Betrand’s soccer team analogy is simple but powerful. It captures the key aspects of working collaboratively as a distributed development team: openly communicating one’s abilities and limitations, identifying one’s interests and fostering them to the benefit of the entire group.

YouTube Preview Image

Open source education – ensuring students develop the skills they need

Published by stevelee on July 3, 2009 in Discussion, Strategy and Policy and Uncategorized. 1 Comment

When I first became involved with Mozilla through working on a Mozilla Foundation accessibility grant, I quickly discovered the impressive open source educational work at Seneca College in Toronto, lead by David Humphry and Chris Tyler. Students on the computer science course get the enviable opportunity to work on projects that immerse them directly in some of the most successful open source development communities, contributing to programs such as Firefox, Thunderbird, Open Office and Fedora (Linux).  These projects are not just academic exercises, rather they are strategic for the open source projects, and students contributions are accepted into the projects. As a result students get incomparable experience working on large code bases and in the process acquire the open source software and community development skills that are highly sought by companies all over the world.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.

Software Sustainability

Published by Ross Gardler on June 30, 2009 in Community, Development and Discussion. 0 Comments

The EPSRC recently issued a call titled “Software Sustainability“. This topic is something that is close to the heart of OSS Watch, so naturally OSS Watch submitted a bid (and, in fact, were named as partners on a number of other bids).

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 collaborative 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-academic 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 receive 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 sustainability lies. There  are examples of this happening with niche software produced in the academic 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 constructive 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 satisfying OSS Watch’s concerns about keeping the community 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 accommodate 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 multiple 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 by enough practitioners to make it viable.

OSS Watch argues that funding projects to experiment 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 successfully 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 awareness 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.

Procuring Software is not (even) as simple as buying a car

Published by Ross Gardler on April 15, 2009 in Business, Discussion and Procurement. 3 Comments

Here at OSS Watch we often get asked things like “which is the best open source twitter alternative” or “which is the best open source financial managment tool?” We don’t answer these questions, and for good reason. Instead we focus on helping people understand how to find and evaluate open source software solutions. In this blog I’m going to try and explain why we take this approach.

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.

A good API is not enough

Published by Ross Gardler on March 16, 2009 in Development and Discussion. 0 Comments

[The post below was written for the JISC "Good API's" project, but I like to get as much mileage out of my work as possible so I'm posting it here too]

We often argue about whether we can trust service X or whether we can hold our data in service Y. This usually boils down to whether the provider of the service is likely to survive, whether the data is secure and whether we can access it in an open format via a documented API. We usually fail to consider the influence we will have on the providers of the service or software exposed by the API, we therefore fail to consider our own futures.

For this post I’ll limit myself to thinking about web based APIs (which we should not do, but since the UK HE and FE communities tend to think API means access to a web service I’ll do the same here). In this sitution we need to consider access to the source code that implements the API. This should be an important part of our decision making process for many reasons , the most important of which is that it increases the options available.

As an example we can consider microblogging, an area that is getting a fair amount of attention in the education sector, see Brian Kelly’s WebFocus Blog for examples.

Twitter, probably the most popular of microblogging platforms, is web based and provides a clearly documented and reasonably complete API. Institutions and researchers are currently considering solutions based on microblogging systems like Twitter. The focus of such efforts include questions like “will Twitter be here in 5 years?”, “what is their profit model?”, “will they start charging soon?”. These are important questions because the instituion will have no control over their own systems if they depend on an external service like Twitter.

For small organisations with no IT support, the use of Twitter is attractive. It is low cost, feature rich and popular. Should the model of use within Twitter change a small organisation can adapt quickly. However, for larger organisations like Universities and Colleges something like Twitter can embed itself, almost unseen, into many different systems across the organisation. For example, it could be integrated into institution wide news networks, the student VLE and and researchers VRE, the student tracking systems and the lecturer feedback mechanisms (to name just a few of the ideas I’ve heard). Clearly an institution can quickly become dependent on a microblogging service and thus the longevity of Twitters support, at current pricing levels, is very important to medium and long term planning.  Unfortunately, there is no way of knowing where Twitter is currently heading and so planning becomes very difficult.

Some commentators argue that depending on any third party solution is too risky and inflexible. Others argue that third party solutions can provide significant cost savings with only a limited sacrific of flexibility. What we really want is a middle ground. A solution in which we can take advantage of third party solutions for as long as the opportunity cost of doing so falls below the cost of developing our own, independent, solutions. Fortunately, there is such a “third way”, that third way is open source software.

Continuing our example of a microblogging service,  an alternative to Twitter is identi.ca. Like Twitter, Identi.ca provides an API for accessing the system and so it can be integrated with in-house systems. It provides all of the features of Twitter and content can be bridged between the two (via the respective APIs). There is, at least on the surface, no significant difference between the two systems.

However, the Identi.ca platform is built using Laconica an open source microblogging tool. This means that if the hosted identi.ca service becomes unsuitable for any reason one can “simply” install Laconica on a suitable server and continue as before. Of course, it really isn’t that simple, by moving away from the Identi.ca server you are taking on the responsibility of maintaining your own server. You may also be forcing your users to rebuild thier social networks on yet another system, which presents a barrier to use. Fortunately, there is a middle ground in this case too. Since Laconica is open source, any third party could set up a company providing Identi.ca like services, including, for example, a group of collaborating universities.

It is tempting to say that an API is good if it provides the functionality we need and the ability to export our data if we decide to move on. However, as we have seen, this is not always enough, not when we need to plan strategically. Web based APIs are, in some cases, merely a way to provide the flexibility to customise systems whilst still locking you into a single provider solution. Experience has shown us that a monopoly in any domain is a dangerous thing.

We must be able to avoid lock-in to any individual providers services. Simply being able to export data from our current service provider is not sufficient. We also need to be able to find an alternative provider. Whilst open source does not guarantee the existence of an alternative it certainly increases the chances of one being created where demand exists. This in turn puts additional pressure on other providers to satisfy the needs of their existing customer base. This pressure often manifests itself through the provision of a more complete and flexible API. This can be seen in the example of the Identi.ca API which not only implements the full Twitter API but goes much further.

UK Government to level the playing field?

Published by Ross Gardler on February 25, 2009 in Discussion, Standards and Strategy and Policy. 5 Comments

In May 2008 OSS Watch published a workshop report with the title “Levelling the playing field: developing a mixed economy for software procurement”. This report focussed on procurement in the Higher and Further Education sectors and recomended that we work to:

  • ensure all solutions use open standards and provide protection against vendor lock-in
  • facilitate better communication with senior managers across HE/FE as to the potential benefits and pitfalls of making use of open source solutions
  • encourage educational ICT bodies with an overview of the sector such as UCISA and BECTA to assist institutions with open source related training and knowledge
  • work to improve the ITT and PPQ processes within institutions

OSS Watch has been funded by the JISC since 2003, part of our remit has been to facilitate the appropriate adoption of open source in the sector, yet the recomendations made in our workshop were largely the same as they were in 2003. Did this mean that OSS Watch was having no effect?

I’m pleased to say that OSS Watch have had some influence on the adoption of open source in the  education sector. For example, we worked with our own funders on an open source policy which was adopted in 2004. Similarly, we worked with BECTA during the creation of the Open Source Schools project (as well as helping BECTA understand what the goals of this project were we continue to provide advice, guidance and materials to the company running the site).

However, when it comes to influencing individual procurement decisions we have struggled to have any significant impact. Put bluntly, there is very little our small team can do when faced with procurement policies and staff that are predisposed towards the incumbent suppliers products.

I was therefore encouraged when the Cabinet Office published “Open Source, Open Standards and Re–Use: Government Action Plan“. This document is intended to put open source software onto an equal footing with proprietary forms for procurement.

As with the 2004 government policy on open source we are assured that “Procurement decisions will be made on the basis on [sic] the best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs, after ensuring that solutions fulfil minimum and essential capability, security, scalability, transferability, support and manageability requirements” and “The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.”

However, this new document goes a small, but important, step further.

It states “Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.” Many commentators have, so far, missed the importance of this statement. The key is in the acknowldgement of “additional inherent flexibility”. This is over and above the flexibility provided by the adoption of open standards.

This “additional inherent flexibility” is a result of having access to the source code. Closed source software can adopt open standards, but they still provide a form of lock-in since there is only one source of customisation and maintenance for that product. When the source is freely available one is able to shop around various support providers in addition to selecting from various interoperating products.

The introduction of competition through open standards is clearly a step in the right direction. However, competition between software providers is also desirable. This is a topic I cover when presenting at procurement related events, and is something OSS Watch believe is very important given that requirements for software usually change as an organisation matures. These changes may not be aligned with the business model of the current support provider.

I’m also encouraged to see that the document identifies a number of actions including “develop clear and open guidance for ensuring that open source and proprietary products are considered equally” (action 1). This is a very complex issue and is something OSS Watch have been trying to do in the education sector for some time.

The problem is that open source and closed source solutions cannot be compared using the same techniques. Whilst the software products themselves can be compared on a feature by feature basis, the softer aspects, such as quality of support, security, flexibility and sustainability of the solution cannot be easily compared like for like. Consequently, it is necessary to change the procurement process itself before any real impact will be seen. Simon Phipps of Sun Microsystems suggests one potential model for a level procurement playing field through adoption led approaches, and warns about how the existing process can be gamed.

Further to the need to change the procurement process we must also ensure our workforce has the necessary skills to evaluate and engage with open source software. Without this skillset policies and action plans will fall on deaf ears, who is going to implement them? I discuss this in my November post “We have an open source future – or do we?“

Despite these concerns, I welcome this document from the Cabinet Office and encourage those with an understanding of open source and, in particular, how it should be evaluated to actively review and comment on the document using the CIO defined tag of #ukgovOSS so that it gets picked up and syndicated on a special public FOSS Aggregation page.

Building FOSS and Education links

Published by Ross Gardler on February 2, 2009 in Community, Development and Discussion. 0 Comments

At OSS Watch we often find that it is hard to find software developers who really understand what open source is about. All too often people think it is simply a way of licensing software.

It is true that the licence is extremely important, critical even. But it is also true that on its own, an open source licence is not sufficient to create good software (surprise!). For good open source software we also need to understand how to manage and engage with users and (if we are lucky) the developer community. This requires a set of skills not commonly taught as part of a typical computer science or software engineering degree. Yet learning to manage a succesful open source project is not difficult.

Recently OSS Watch have been working on some plans to start solving this problem. More accurately, we have been looking at ways to bring together the excellent work of others and tie it into formal education and work based learning. These plans are still solidifying, but they are progressing well and we now have a very impressive line up of collaborators, ranging from little old OSS Watch all the way up to some of the heavyweights of the open source software world.

Many of these  people, and some others, will be meeting at a pre-FOSSDEM EduCamp. Anyone interested in these issues should consider signing up for the event which is likely to be both useful and fun.