[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 09/10/10 18:12, Neil Williams wrote: > On Sat, 09 Oct 2010 17:16:15 +0100 > tom brough <tombrough@xxxxxxxxxxxxxxxx> wrote: > >> Doing a quick audit of FLOSS that would be useful to Schools and in >> particular looking at school focused software portals like >> SchoolForge, its disappointing to see that a lot of the listed >> projects have not been updated in at least a year some a lot longer. > > Most of those are one-person "teams" which may sound as if things get > updated often but it actually means "one-person managing many other > one-person projects" (like me). Also, don't make the mistake of assuming > that updates == good code. Stable code needs less updates, so check the > number of outstanding bugs and assess their severity. Conversely, > projects that constantly change may actually indicate a team in flux, a > team engaging in internal flamewars and only ever fixing fires without > actually thinking about the code overview. Stable code can be simply be > good code which doesn't need frequent changes. This is true, but it does indicate (stable or not) that the project has stagnated. Putting a Managerial hat on for one moment (yuk) I could understand how nervous management would be to take a product that looked like it was not being developed or moved on. It might be acceptable in some circumstances but the world in general doesn't tend to stand still (Torbay Council being the exception that makes the rule). > > There is no single measure of whether a project is alive or dead - > except actually contacting all the team members, asking and waiting > for a response. > > "Quick" audits are more than pointless - IMHO a quick audit actually > hinders free software a lot more than the activity or lack of activity > of the projects themselves. (Even then, remember that all these people > are volunteers and will reply in their own time.) > >> Also a number of broken links on these sites are not impressive. > > That only matters if the links are still broken after trying to notify > people in the team. How many teams did you try to contact as part of > the audit? Was the audit anything more than 30 minutes on Google? > I hope you don't think I was being critical. It was purely observation. I did manage to track down urls for some of the broken links, however no redirection from original pages or just no pages at all made this difficult. Indeed it was approximately 30 minutes of Googling, but in my defence I have completed approximately 5% of the first trunch of work. If my findings are typical the other 95% is going to be an uphill task, to say nothing of the rest. If I was critical it was of the portal sites not keeping tabs on the projects. >> It >> is inevitable that projects will fall by the wayside, but sadly this >> does not help to promote the open source cause. > > Wrong. Abandoned upstream projects are never bad for open source / free > software because the licence means that anyone with even a slight > interest can just take a copy of the code and fix it. If the code > really has gone to bitrot, there is usually something which can be > recovered from the remnants - even if it is just the documentation. > Not much consolation to a manager who has invested in a product and then finds there is not enough interest to keep it going. > Dead upstream teams are only a problem when nobody has access to the > code. If the ideas behind the projects are sufficiently interesting, > someone will usually take on the project. That's the thing, free > software doesn't come with a warranty, including fit for purpose. > Therefore, it is not possible to audit free software on the basis of > being fit for purpose. It is what *you* can make of it. If you need > more from it, recruit people to help you fix it. Maybe the older kids > could actually fix the code for the younger ones as an educational > challenge.... > > There are plenty of evaluation processes for open source software go and check open source watch, which is part of JISC. Some if not all of these (off the top of my head) include evaluation techniques for project continuity. On the subject of additional functionality and maintenance I'm not disagreeing with your point but what school could afford to hire programmers to provide extra functionality or even keep a product maintained? If anything is important to a managerial group it will be continuity of service. Even "big" projects like MySQL and OpenOffice are struggling with this. Im not saying that proprietary products wont struggle too or even disappear, but if you pit open office against MS Office and MySQL against SQLServer, which products is a manager going to have faith in having continuity of service in support. You may well be able to find objective ways of saying the FLOSS equivalents are better codes and superior in design, but would be be able to find any model where these products would score better on continuity risk assessment? I'm trying to evaluate the managerial mind set and its attitudes towards open source software. They have some valid concerns. Saying that projects will survive ... the code will be picked up by someone else (eventually) and that good product will survive is all well and true.... BUT management will want more assurance than simple hope, optimism or even past performance. The reason I askes these questions .... I'm actually equipping myself for the possibility of being a parent governor at a school where I will have influence over future strategic decisions. I hope to get open source firmly established on the radar, but I need to be able to offer clear concise and objective advice. The arguments you give are as equally valid as the concerns I have raised, but the concerns will not go away, unless dealt with objectively. What we need is some sort of Open Source underwriter to pick up the tab on key open source software at an international level. How or if that could be implemented is another matter. In many respects certain open source product should be treated with the same respect as rare historical artifacts, paintings and sculptures. What I would like to be able to do at the end of this process is to offer a suite of applications that befit a set of diverse problems that a schools information systems (admin and academic) will be required to deal with, and be able to offer such solutions with a modicum of re-assurance that the very projects being suggested will be vibrant still in 5 years time. There are serious practicalities that need to be addressed in this research and perhaps some framework for maintaining support and monitoring progress can be teased out. Food for thought. Tom. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq