Project SWOTing

One of the JISCRI project reporting requirements is a SWOT analysis of each project. It makes sense to attempt our first SWOT analysis sooner rather than later and update it using the comment form as we work through the project. Your comments are very welcome. Surely a bad SWOT analysis is one undertaken by a single individual (like this one!)

SWOT diagram

I think one of the main strengths of the JISCPress project is that we’ve effectively been developing it since February, when Tony and I set up WriteToReply. JISCPress is basically a re-thinking, re-working and further development of WriteToReply for a specific community and we can apply the lessons learned through WriteToReply, to the planning and development of JISCPress. In this sense, we’ve got a decent head start really and both Tony and I know where our own strengths and weaknesses, as well as our own particular interests lie in the project.

Another strength worth highlighting is the range of skills we bring to the project. I’ve been running different WordPress MU installations here at the University of Lincoln for the last year and have several years’ experience tinkering with Linux servers. I’m finding working on AWS to be an enjoyable and welcome learning experience.  Tony prefers to stay away from the bash command line, instead focusing on the way the data published on JISCPress can be repurposed, cross-referenced, syndicated and mashed up with other web services. He’ll also be looking at what value can be gained from the Google Analytics and Piwik APIs.

Anyone that knows a bit about CommentPress (now called ‘Marginalia‘), will understand that Eddie brings an excellent understanding of WordPress code to the project as well as some pretty advanced javascript skills. Eddie has always led the development of CommentPress/Marginalia and as it provides core JISCPress functionality such as paragraph level URIs and commenting, it’s a strength of the project that we have him on board. Were he not on board and we were reliant on another developer to work on CommentPress code, I would consider this a risk to the project. To quote from his site:

I believe in rapid prototyping, open-source, collaborations instead of competition, quick releases, smalls teams, debate, creative thinking, and transparency.

That’s exactly the type of person we need to work on this project.

Finally, Alex is a keen student of computing at the University of Lincoln with good PHP skills. As a student, he’s flexible with his time and not wholly reliant on the project for his income and it’s reassuring to have him working locally (and in the same time zone!). All in all, I think we’ve got a good spread of skills and interests on the team.

While I’m thinking of strengths, I’m confident that using Amazon’s infrastructure to work on the project will prove to be a strength. It allows us to work on the project in an environment that is independent of the University of Lincoln’s IT infrastructure.  I’m very lucky here at Lincoln to have root access to my own Linux server to work on, despite not being a member of the ICT department. I’ve no complaint at all about our ICT department and enjoy working with them, but on a rapid project like JISCPress with four team members working independently and the potential for contributions from the open source community, I’m pleased that we have our own space to work and I don’t need to bother my IT colleagues to restart the virtual machine or make changes to DNS records.

On the other hand, the membership of the team could be seen as a weakness. We’re not a tight team of developers working in the same institution but rather relative strangers working, for the most part, remotely and in Eddie’s case in a considerably different time zone. This could result in poor communication and lack of motivation if we let it and I hope that the pillars of communication in open source projects that we’ve set up (IRC, mailing list, code repository, wiki, blog) will help us stay in touch and motivated.  However, one of the main benefits of this project for both me and my employer, is being able to test this way of working on development projects. We don’t have an in-house team of web developers who could be pulled into this project and as much as I’d like my department to hire a researcher/developer or two, it’s not going to happen. So in order to work on JISCRI and similar funded projects, I need to show that this is an effective way of working. I hope it succeeds, because I like working on these types of projects and in order to innovate in our use of technology to support research, teaching and learning, we need to have the experience and capacity to undertake proper R&D and not just theorise about the potential of technology in the HE sector.

threat to the project is that JISCPress is principally a tool for JISC document authors to publish funding calls and JISC project managers to publish their final reports. We need their buy-in to the project, not only to make it feel worthwhile but also to steer the direction of feature development. JISCPress might be seen as complicating JISC employees’ work, pushing something on them that they never asked for. It might also be seen as yet another requirement from JISC to Project Managers. I take this threat seriously, but I don’t let it worry me too much. JISC has made the decision to fund JISCPress as a ‘demonstrator prototype’ and there’s no obligation for them to put it into production use. They also recognise that we’re building a platform that could equally be of value to other organisations. WriteToReply and JISCPress are just two examples of what we’re developing. WordPress is a popular CMS and the work on Marginalia and additional features that we’ll be developing, can be cherry-picked or taken wholesale and put to good use. All code is developed under a GPL or compatible license. (Note that this has to be the case, because we’re developing for WordPress which is licensed under the GPL, calling functions in WordPress core code – not all WP plugin and theme developers understand this!)

Finally, for now, the project provides opportunities for anyone to get involved and in turn, by working in public on an open source project, I hope we’ll attract others who like what they see and want to contribute in any way at all. Comment, test, review and contribute code, if you can. Join the mailing list and introduce yourself. Working this way, with an emphasis on openness and transparency, I hope that opportunities arise that we don’t yet know about. One that we do know about is Google Wave, due out in September, and if we keep that in the back of our mind, there might be an opportunity to exploit this new and exciting platform and protocol. Maybe we’ll develop a JISCPress gadget for Wave that allows realtime comment and discussion on a document from Wave? Maybe JISCPress will largely become a ‘hidden’ CMS that is used exclusively by via publish and subscribe protocols such as RSS, AtomPub, XML-RPC, and Wave/XMPP?