Archive for the 'collaboration' Category

Why freedomware services are important?

Free network services, or freedomware services, matter because they bridge communication channels between people across space and time.

The digital equivalent of the Speakers’ Corner in London’s Hyde Park in the Internet Age are WordPress.com, Youtube.com and Flickr.com.  In fact the ‘speech’ from the saying ‘free as in speech, not as in beer’ is the perfect example of a freedomware network service. Free speech, upon which the free market relies on heavily, relies in turn on free press which is still a service.

I started to get involved more with free(dom) software when I began to realize that working collaboratively is much more effective than individual work. That was after I read an essay at Life is not read-only.

Soon after, I learned that other people need to work collaboratively, too. So I wanted to expand the posibilites of collaborative working from software creation and Wikipedia to many other fields of knowledge. There are already services that build and enhance this collaboration: for example, vector graphic artists build OpenClipArt, lawyers and law officers build Jurispedia, Identi.ca helps users share small tidbits of information. In addition to creating a free culture that can be used in free software, such participants also understand better than the average non-programmer how the freedom software world works and are most likely to be the best at spreading the word amongst their kind about freedom software and culture.

What is a network service?

A network service is an instance of a software that runs reliably for a period of time and which links together people over space and time.

But who brings together the software needed to run a service? That would be the service maintainer(s). She/he is the one who wields the power of the software to enable communication between people. And linked people communicating build together culture.

To sum up: culture builds on services, which in turn builds upon software and maintainer’s work.

Standard for communication between project infrastructures

I see the way forward as a Foundation Board (free to join as individual contributors, not permited for companies) that establishes community standards on all collaboration resources.

Such a standard should include what kind of information should be contained in a bug report, and this could in turn be implemented as a RDF resource. As far as I have seen LaunchPad already provides RDF resources for bugs. This way there would be an easy transition between different project infrastructures: maybe one will be able to take all the bugs (closed or open) her/his project has on Source Forge and have them automatically imported, as a batch, into LaunchPad or CollabNet.

For project infrastructure there are also tools like Maven, which ads the goodness of dependency management. We should check the effectiveness of Maven and similar tools, find their weakest spot and make a request to the responsible team to improve that feature.

I also think we need to research more thoroughly a free software development methodology. We do not like some Agile or XP programming ways of doing things, so we need our own methodology/-ies. There are some academic studies on our development model but they are scatterd across different web sites. The idea is that we do need a more structured, integrated documentation tool on how we do/should work.

This research is needed to prepare the infrastructure we will use 2,4,8 years from now, when both the number and the diversity of contributors to our community will grow immensely.