ReportTool launched

ReportTool is a simple web application for creating, editing and viewing reports on students’ work. It was created by Stephen Butterfill, a philosophy lecturer at the University of Warwick.

In classic hacker fashion, Steve had an itch that needed scratching. Like faculty in every university department, the faculty in his department had to create, track and distribute reports on students’ progress. From Steve’s point of view, it is much easier to do this on the web than on paper. Since he couldn’t find a free and open source web application to meet his need, he set about building one of his own.

Along the way Steve needed to learn java and web programming. When you’ve got an itch, I guess, you do whatever it takes to scratch it. And, since he is one of the brightest guys I’ve ever met, it wasn’t long before he had a working application.

First make something that works. Then make it better.

Having built an application that is adequate for his own needs, Steve started thinking about sharing it with others. Anyone building an application like this is almost certain to be using so many free and open source development tools that open source just seems like the natural way to go. But how to go about it?

That’s when I got involved with ReportTool.

I have been helping Steve set up a project site for ReportTool. Our modest goal is to gather input from potential users, those willing to try out the live demo, or indeed those brave enough to download the prototype. Future development of ReportTool – including discussions towards which open source licence would be most appropriate for it – will take place out in the open on the ReportTool development mailing list.

It’s been fun working with Steve. And fun setting up the ReportTool site. But I suspect that the real fun is only just beginning…

Being open

How open is your project? It’s a question that should be asked of any open source software development project. It goes without saying that the software being distributed in such a project has an open source licence. That ensures that the software itself is open. What about the project? What about the way the code gets developed?

Sometimes I tell people that the licence is the thing. Without an open source licence, it’s just not open source software. And that’s true. But it’s not enough.

Pia Waugh made just this point to me when I met up with her last week. Amongst a million other things she does, Pia also works for ASK-OSS, the Australian equivalent of OSS Watch. She argues that without open communities, open content, and open standards, open source software is stunted. More and more I begin to see her point.

Yet being open is hard sometimes.

It takes practice. Moreover it admits of degrees and may need to be approached one step at a time. A good start is to set up an open development discussion list. But if you do, treat it with respect. Once you’ve got such a list, then all development communication needs to take place on it.

Either the project is open and this open development discussion list reflects that, or its openness is a sham.

Try it on for size

These days almost any webhosting company that offers a GNU/Linux package also offers a plethora of one-click installs of free and open source content management systems, database servers, blogging software, wikis, control versioning systems (cvs), and more. With so much choice, you will want to try it all. And you should. It’s fun, and you will learn a great deal.

There is probably some marketing term for a product that promotes itself by letting potential customers use it. In the case of open source software, that trial use merges seamlessly with actual use, with no discernible transition or acquisition cost.

So, I come, I try out some software, I like it so much that…I just keep using it.

The opportunity to try something that isn’t a cut-down version, or a lost leader for a “pro” version, is one of the great strengths of free and open source software.

Recently I have been learning how to administer Mailman. Just another one-click install option from the webhoster for a project site I am helping with. I already know it does the job I need it to do. I need to set up a development discussion list and an announcement list. I know this because I’ve engaged with Mailman interfaces as a list subscriber on countless open source project sites. Now I’m discovering that administering lists is reasonably straightforward as well. What should I do now?

Just keep using it!

In the news

It’s always a little embarrassing when you find yourself in the news, Public sector catches wikimania. I was interviewed back in December about OSS Watch’s Wiki. Freelance writer for The Guardian Steve Mathieson was interested in why we had gone down this route and how we were planning to avoid some of the problems Wikipedia was experiencing on trust issues.

To be honest, the interview took place on the day before we left for Canada for Christmas, so I’d largely forgotten about it when I was contacted by the photo desk at The Guardian in January and asked to make myself available for a photo shoot. Get real! But then the article failed to appear in January. So I forgot about it again.

Then yesterday, after a long but enjoyable advisory committee meeting, I found an email in my inbox from Steve letting me know that the article had come out. No photo of me (thank heavens!) but a really nice piece. Good for OSS Watch, good for JISC (our funders), good for Oxford University (I think).

Still, a little embarrassing though 🙂

ReportTool – setting up a project site

I am assisting my friend, Steve Butterfill, in setting up a project site for a software application he wrote called ReportTool. Steve’s plan is to eventually release ReportTool under an open source licence. My job is to help him think through the process involved, as well as pitching in to help on practical things like writing web pages and participating on mailing lists and such.

Heavens, there is such a lot to do. Even for the smallest of projects. First impressions, of course, are important. So we want to get as much right before the site is announced to its potential user/developer community.