Archive for January, 2008

What should you protect in Open Source?

Published by Ross Gardler on January 28, 2008 in Business and Legal. 2 Comments

Marc Fleury was the original creator of JBoss which was later bought by Red Hat for approximately $350 million in initial consideration, plus approximately $70 million subject to performance. Clearly Marc has learnt a thing or two about sustainable open source.

Marc recently wrote a blog post advising on what to protect in an open source project in order to be able to exploit the software and or services around it. One paragraph jumped out at me as it reflects the advice OSS Watch give:

Protecting IP in OSS is extremelly important. The only “private” property that exists in OSS are 1- brand 2- URL. Both are obviously related but really you need to protect your brand name, in other words REGISTER your trademarks, use them, declare they are yours and enforce the trademark, meaning protect against infringement. Other products, specifically based on your product should not include your name. Consultancies will be able to say they know and work with your “product name” but they cannot ship products using your trademark. Educate yourselves on brand IP, that is a big asset in OSS.

Marc says the URL needs the same protection, I’d agree.

Registering trademarks is not difficult or expensive. If you think your software may be viable in the medium to long term then register your trademark today, you have nothing to lose.

eXtreme Programming for Open Source Software

Published by Ross Gardler on January 22, 2008 in Development and Discussion. 0 Comments

My day job no longer involves any programming, although I still play around on open source projects for fun (yes, I enjoy coding). There is something missing in this work, as I’m no longer a member of a team of developers I no longer practice eXtreme Programming (XP). I used to enjoy activities such as pair programming and stand-up meetings, they are social and resulted in higher productivity. In distributed open source teams these practices are simply not possible.

Recently two things happened that made me think more about eXtreme Programming in Open Source Software. Firstly, I received a copy of “The Art of Agile Development” to review and secondly I was invited to run a session, along with Neil Chue Hong of OMII-UK on Agile and Open Development at a forthcoming JISC e-Inftrastructure workshop.

In planning this session I recalled that whilst most open development methodologies are agile, it is not possible to apply either of the two common agile methodologies, eXteme Programming and SCRUM, in an open development project. This is because many of the practices in these methodologies require co-location of team members and customer representatives.

Then I turned to The Art of Agile Development. A table caught my eye, in this table the authors had listed the practices within XP, Scrum and a modified version of XP discussed in the book. What caught my eye was that a large number of the practices were not explicitly used in one or more of the methodologies. They were listed as either not applicable or implied.

This reminded me that agile programming is about adopting and adapting a set of agile processes to best suit your project and team. The eXtreme Programming and SCRUM methodologies are only examples of successful groupings of practices, projects are not supposed to feel constrained by them.

This set me thinking, Is there an eXtreme Programming for Open Source Software (XPOSS)?

A quick search of the Internet failed to turn up any defined methodologies. Yet I am acutely aware that whilst some XP practices don’t work in open source, many others map directly to typical open source development practices, so why is there no defined methodology?

Perhaps the lack of a defined XPOSS is a result of the fact that most open source projects are organic. Their practices evolve over time as the community dynamics change. There is no need (or desire) to formally define the development process because the community understands it. Besides, why bother writing it down, doing so only produces another document that needs to be maintained. The process could potentially change each time a new (non-core) contributor arrives. That is, someone wishing to donate her or her companies time, but not wishing to be constrained in how they utilise that time.

Perhaps we need a “best practice” XPOSS. A resource that can inform people new to open development in the same way that XP and SCRUM inform people new to team based agile development.

OSS Watch are considering documenting the open development and eXtreme Programming practices we’ve experienced. The intention is to build and define an agile methodology for open development. We’d welcome insights and pointers from anyone with experience and ideas relating to either agile or open development (even if you want to tell us it would be a waste of time).

You can contact us through the comments here, or, if you prefer, via various OSS Watch contact methods.

Ohloh opens up – hurrah!

Published by Ross Gardler on January 15, 2008 in Development and Software. 0 Comments

Simal is a project registry tool that OSS Watch are building for internal monitoring of projects we are here to support.

Ohloh is an open source network that connects people through the software they create and use.

Some time ago Ohloh published an API that enabled me to get at their data. This was great for Simal because instead of producing a Description of a Project file for every project I could point at Ohloh and it would give me most of what I needed. We use this API extensively. However, I was always concerned. What if Ohloh disappeared or started charging more than we could justify (it’s free right now)? One of our primary data sources would have disappeared.

I also wanted to get at the Ohloh code. Some of the projects we work with do not have publicly accessible version control so couldn’t appear in Ohloh. I want to be able to run a local copy of Ohloh to capture data about non-public projects. Unfortunately Ohloh was not open source, so that was that.

But that has just changed.

Well done Ohloh!

The best collaborators will win

Published by Ross Gardler on January 2, 2008 in Community and Development. 0 Comments

Raven Zachary (451 Group Analyst) was reported to have said “Go-it-alone commercial open source will lose. The best collaborators will win.”

In disecting this statement we must first attempt to understand what Raven means by “commercial open source”. I suspect he means open source that is sustainable through commercial exploitation. If this is the case then I think we can safely replace the word “commercial” in this quote with “sustainable”. Where sustainable means that the software undergoes continual development that is supported financially by some means or another.

Recognising that open source software costs money to develop is key to creating a sustainable open source project. Too many people fall into the trap of believing that an open source licence is enough to make the software take on a life of its own and, almost overnight, take over the world.

Sorry folks, that’s not how it works.

To create sustainable open source software someone has to foster a community around the software and to lead and coordinate the communties effort. Failure to foster this community will eventually result in the software being abandoned (the originator has lost interest) or the code will be closed (the sponsoring commercial party is fed up with giving whilst recieving nothing in return).

Don’t worry though unless your software is truly something special, or at the very least has the potential to be something special, this won’t take many hours in the week as communities typically take their time. They slowly congregate around the best candidates, occasionally asking a question, maybe even offering to help, but rarely doing much more.

Over time, the number of people in the community grows and the activity increases. It is your job to ensure that the community, right from the off, is encouraged to be self supporting. Failure to foster a self-supporting community can be almost as bad as failing to foster a community at all. This is because a community that is not self supporting is one that only takes from you, draining your resources and ensuring you never have time to devote to the software itself.

Conversely, a self supporting community will help you provide user support, will document new features and commonly asked questions, will report bugs, make feature requests, provide patches and, occasionally, make significant contributions to your software development efforts.
So how do you build that community?

There are many things you need to do, but perhaps the most commonly overlooked item is to ensure that any investment of time and resources from a third party is acknowledged, accepted, protected and appreciated. Furthermore, any sustained and or significant contributions should allow the individual to influence the project directly. That is, your project should describe how third parties can become a part of the project itself. This does not mean you need to cede control (unless you want to), but it does mean that people wishing to contribute can do so safe in the knowledge that if you were to change jobs tomorrow the project could survive, and thefore their investment of time will not be wasted.

Key to this is communication. The first thing you need to do when setting up a collaborative open source development project is to clearly define how the project is going to be run, who has decision making powers, how others can contribute and how others can influence the projects sustainability. Initially this need not be a hugely detailed document, it simply needs the scaffolding on which your communities “bye-laws” will be built.