Start with the Low Hanging Fruit with Software Development

A key component of Freedom Fone is the software development we will undertake over the next two years. Last weekend Brenda and I met with a handful of people who have experience with open source development projects like those we’ll be undertaking. We got to share our ideas and experiences to date developing the Freedom Fone prototype, and we benefited from their contributions and suggestions.

Much of what they recommended resonates with some of David Cohn’s blogs and the importance of being iterative. See for example:

• Eliminating the Fear of Being Open
• Growing a Community and The Importance of Being Iterative
• Starting Small and the Importance of Being Iterative

Some of the top tips from our development launch meeting included:

Start with the low hanging fruit

You want to build an interest and a sense that something is happening around your project from as early on as possible. So do a few things early on which are quite contained and which build this sense of progress – the website, the blog, the targeted deployment of the prototype of the software, etc. That way, even if it takes six months before the full, stable version of your software is developed, people can still get a feel for what you’re trying to do, and there is a vibrant, dynamic forum through which people can contribute their suggestions.

Scope viciously

It’s tempting to try and cram all of the functionality you want your product to have into an early version. Resist That Temptation. Rather, be deliberate and focussed about what features you choose to be developed in the first phases, and how you prioritise them. If your scope is too broad, your developers will start to lose interest as the process drags out.

Avoid spec creep

Once you’ve settled on a feature set for a given version of your software with your development team, stick with it. Changing the goal posts during a version, or asking your developers to add “just this one more thing,” will make it difficult for your developers to keep their momentum.

Choose your early deployment partners strategically

The best way to build interest around a funky new project is to demonstrate just how funky – and relevant – it is. We’ve known that we want to engage with a few capable, technical partners to put Freedom Fone through its paces, and to demonstrate it in action in a few different contexts, from very early on. Our launch meeting reminded us that, in addition to the technical capacity of potential partners, we also want to vet them for the type of deployment they’ll be doing with it. The more interesting and engaging the content they incorporate into the system is, the more rich and exciting our case studies of their experience will be – and the easier it will be to spark other people’s imaginations and interest in the project.

Actively build the community around your project

Freedom Fone will be an open source technology that will depend on a community of developers coming around the project to ensure its continued evolution and usefulness even after our Knight News Challenge funding is over. Some in the group believed we should open up our software immediately, starting with the prototype, in order to build this community from the ground up. Others in the meeting, including Brenda and myself, thought there was merit in waiting until we had at least the full, stable, version 2 of the project developed – in six months time or so. We thought we’d then be in a better position to support project deployments and share our experiences with others in the open source development community. Either way, the group was clear that at the very least, within the last 6-9 months of Knight funding, the software and its code should be fully available – and that we should actively be engaging to generate this sense of “development community” around the project, to ensure that it lasted beyond the Knight funding.

Just start

We have a prototype version of our software that can do about 80% of what we want the first full, stable version of the software to do. The more we can work with it now, before our development team has even started on version 2, the more feedback we’ll have for them about what does and doesn’t work. And the better we’ll be able to inform the spec for version 2 and beyond. There’s a temptation to wait until we have the “perfect” version up and stable – but the meeting urged us to just get started with what we have, to speed up what will probably be a steep learning curve.

We’ve come out of our development launch meeting with our client requirements which we’ll be using to recruit our development team and iron down the technical specifications for the next round of development. Tips and suggestions for working with developers are welcome!