Master on Libre Software Planet

Llego a un informe comparativo sobre el IRPF [PDF]  que sitúa a España como uno de los países con más altos impuestos del mundo. Apenas 4 puntos por debajo de Suecia (el modelo intervencionista estatal por excelencia) en todos los tramos y de los menos progresivos de la UE (en países como Alemania, Finlandia o Reino Unido las rentas por debajo de 10.000€ no pagan llegando a tasas similares a las nuestras para las rentas altas).

Hoxe, a web está de folga. Estos días estase a debatir no congreso estadounidense a coñecida como lei SOPA que recorta liberdades dixitais. Estamos en pé de guerra. Nesta batalla, persoalmente pouco podo facer máis que darlle publicidade ó que ocorre e pensar en modos futuros para que non me afecte: non olvidemos que a globalización é interdependencia e que, gran parte da miña nosa actividade online está mediada por compañías estadounidenses de contidos (ás que máis lle pode afectar a lei SOPA). Por sorte, na maioría dos casos que me afectan éstas adhírense á folga da web: dreamhost, wordpress (capturas), wikipedia, google, etc. Pero isto non me reconforta. Simplemente me mete présa para seguir profundizando no noso plan de independencia dixital.

Actualización 18 de Xaneiro: este blog ha redirigido las peticiones de visitas a la web de la huelga. Gracias a los creadores del plugin que hicieron posible que esto fuese posible para cualquier usuario de la red odiseus de un modo trivial.

Actualización 22 Xaneiro: Clay Shirky axúdanos a reformular o debate sobre a SOPA e PIPA neste video.

Fran acaba de postear sobre la recuperación de la deducción por vivienda. No puedo sino hacerme eco de otra de las medidas estrella del plan de choque del nuevo gobierno: prohibir los pagos en efectivo para luchar contra el fraude fiscal. Otros, han articulado un buen análisis sobre esta medida. A mí me provoca entra risa y miedo esta deriva hacia el hiperestado por encima de nuestras vidas.

A good map to navigate through the themes, authors and styles of the so-called scifi.

Las mafias no son sólo una de las pocas fábricas que todavía tienen capacidad para contratar, sino que, en Italia, son “el primer banco”. En no pocos lugares son ya una competencia directa al estado como proveedor de bienestar.

Black Mirror. La serie de las navidades. Hace unos días leímos en 5ª temporada: «Son tres capítulos que juegan con la exageración y la provocación para retratar a una sociedad adormecida  y dominada por la tecnología.». Qué exageración, pensé. Pero ese aire ciberpunk me supera, y al par de días leí el artículo de Charlie Brooker presentándola: «the dark side of our gadget adiction». Y me convenció más. La descargamos. No cometáis el error de tardar tanto como nosotros. Si aún se estilan los propósitos de año nuevo, Black Mirror es el espejo donde tenemos que mirarnos. Porque, en el 2012, se necesitan de nuevo esfuerzos en favor de las libertades civiles en internet. La caballería e infantería se atisban ya en el horizonte.

«Se Díaz Pardo fose como Steve Jobs, nas cuncas de Sargadelos só poderias tomar café Las Candelas.»

In memoriam (via).

Aunque este año pude disfrutar de pocas películas y casi ninguna novela, he descubierto joyitas que merecen ser destacadas y recomendadas para este 2012. Una de ellas es GATTACA, una historia que afronta la pregunta de ¿cuáles son los efectos sociales del determinismo genético? Porque…

«If we can use genes to find out who’s biologically suited to specific tasks, and to calculate estimated life spans for every newborn, how would that reorganize our society? If, for example, we knew that the odds were against a given presidential candidate to survive a single term in office, would anyone vote for him or her? And, as British authorities have recently proposed, if we can identify the genes associated with criminal behavior, why not test every single child, and create a pre-emptive database of would-be offenders?»

La historia gira en torno a dos personajes principales: por un lado, Vincent (Ethan Hawke), clasificado como “no-válido” para ser astronauta, debido a que su registro genético dice que tiene las condiciones para un paro cardíaco muy joven; por el otro, Jerome (Jude Law), una estrella de la natación con un perfil genético immejorable que, al sufrir un accidente de coche, queda inválido.

A través de la relación de Vincent con su entorno, GATTACA reflexiona sobre la delgada línea que separa la terapia y el determinismo genético. Como cuando sus padres están pensando en tener un segundo hijo y el genetista les dice…

«We want to give your child the best possible start. Believe me, we have enough imperfection built in already. Your child doesn’t need any more additional burdens. Keep in mind, this child is still you. Simply, the best, of you. You could conceive naturally a thousand times and never get such a result.»

Y al tejer esas relaciones, los incentivos que ofrece la terapia genética construyen una sociedad cuyo principal valor es el determinismo genético. Sin duda una de las mejores películas que uno puede ver a lo largo de 2012. Altamente recomendable. Y recordad… «There is no gene for the Human Spirit».

Desde hoy mismo este blog se encuentra alojado en la Red Odiseus, y de paso con nuevo diseño. La Red Odiseus es una iniciativa creada por Fran y Andrés, y a la que después me uní yo mismo, para además de tener un hosting propio, alojar los blogs de los amigos y echarles una mano para montar la infraestructura y con los problemillas que les surjan.

Ahora mismo tenemos 9 blogs en la red y con previsiones de que se nos una alguno más en breve. Además alojamos las páginas de alguna que otra asociación a la que estamos vinculados de alguna forma, y alguna que otra lista de correo.

Para finalizar el post rescato algo que me dijo Andrés cuando me contaba esta iniciativa y me metía el gusanillo: “Para que van a tener nuestros colegas el blog en blogger si nosotros les vamos a cobrar lo mismo y aún encima les damos cariño”.

Si has leído Jeniffer Gobierno, esta noticia te llevará a un mundo conocido. Si no lo has leído, no podría recomendar una mejor novela para los tiempos que corren.

Un bo artigo da BBC sobre a crise na eurozona faime reflexionar de novo sobre o tema e recordar un video de Garicano sobre as deficiencias económicas de España. Ser os primeiros da clase en cumplir co pacto de estabilidade non nos evitou a recesión, o noso problema foi a débeda privada, síndrome de novos ricos. E a saída agora non está clara: ¿aforro ou inversión?

Great time at Master Software Libre teaching Physical Security and Cryptography contents this year. Two key areas at Information Security and Privacy.

These lessons were the first ones happening before my usual lessons on Networking, Security Networking and Linux Kernel.

On Physical Security time we worked on well-know physical system security methodologies, together with two new relevant topics: environmental design and design and evaluation of physical protection systems.

It was a lesson covering broad and detailed topics; ranging from designing defensible spaces, where you are able to use different elements and aspects to get natural social control and crime prevention, till a full description of technology and sensor availability to protect different facilities. Security standards or some notes to understand social behaviour (The Bronx study case) were worked out too.

On Cryptography, we walked along its history and development in order to understand cryptographic models and current crytographic systems, free/open software tooling, integration and usual use cases. At the end, everybody got their crypto stuff in place, ready to take part in keysigning parties and next social community events.

Ah! I almost forgot. This year, students will elaborate on the right design to build a safe and secure physical protection system for one embassy.

«Just as demagogues may subvert democracy, so self-promotion may subvert meritocracy.»

Open Source Projects and the meritocracy myth

«Institutional memory comes in two forms: people and documentation. People remember how things work and why. Sometimes they write it down and store that information somewhere. Institutional amnesia works similarly. The people leave and the documents disappear, rot, or just become forgotten (as it were).»

Sign: an engineer. On institucional memory and reverse smuggling.

Estoy leyendo a ratos Coders at work, un libro de entrevistas a programadores inspirado en lo que hizo The Paris Review con su serie Writers at work, por la que pasaron Hemingway, Capote, Borges, …

He empezado por aquellas que más me sugerían, por ejemplo, la de Jamie Zawinski, uno de los líderes detrás de la liberación del código de Netscape y cofundador de la fundación Mozilla; seguida por la de Brendan Eich, también cofundador de Mozilla y creador de javascript. Me ha gustado descubrir no sólo su trayectoria personal, si no el ambiente que se respiraba en Netscape en aquella época. Totalmente imprescindible como complemento el documental Code Rush:

Al acabar la de Eich, he empezado con la de Douglas Crockford, creador de JSON y uno de los principales gurús del lenguaje. Mundialmene conocido por Javascript: the good parts y sus talleres de introducción a Javascript. El libro y la serie completa son una deliciosa joya para todos los que aspiren a saber algo del lenguaje. De entre todos los videos, por contexto, recomendaría ahora el primero, que versa sobre la historia del javascript (según sus propia interpretación):

Estoy disfrutando enormemente del libro. No sólo me sirve para conocer más ciertos aspectos de nuestra reciente historia (la de la informática y sus empresas) si no también para de algún modo entrar en el proceso creativo de grandes programadores, cómo se enfrentan ellos a la tarea de programar. Conocer, de cara a mejorar el mío propio.

Fran ha estado recientemente en las jornadas de economía social hablando sobre desarrollo y propiedad intelectual. No os perdáis su último post. Hago mías cada una de sus palabras. Os recomiendo acompañar el resumen con este video de David.

Mañana estaré volando a Barcelona para asistir a las JIDEE 2011. El jueves 10 tendré el honor de presentar IDEPo, el nodo IDE de la Diputación de Pontevedra con datos EIEL, un proyecto financiado por la Diputación de Pontevedra y la Xunta de Galicia. Un proyecto que hemos liderado desde iCarto con la colaboración de Cartolab.

No se me ocurre mejor acompañamiento para un proyecto como éste donde el conocimiento de los datos es crucial. Poca gente en España conoce los datos y procesos EIEL tan bien como ellos, una pequeña muestra es el gran trabajo que han liderado con gvSIG-EIEL. Si queréis saber más de IDEPo o simplemente hablar de iCarto, estaré disponible en el WTC al menos todo el día del jueves.

Chega o Samaín, literalmente o fin do verán, festividade celta que supoñía o fin da temporada de  colleitas e era considerada o fin de ano celta. En Galicia, é tempo tamén de chorar ós mortos. A miña rutina hoxe é despertar cedo, conectar o RSS, ler as noticias. E chego a “Los médicos deben de recetar desde hoy por principio activo y no por marca comercial“. Así, gracias á necesidade económica -impulsada por Galicia, a comunidade autónoma que máis gasta en medicamentos por paciente- o impulso de xenéricos é unha realidade. ¿O principal beneficiado? As arcas do estado, que se aforrarán cerca de 2.000 millóns de euros. Pode que tamén a industria de xenéricos española. Recordo agora as primeiras charlas, anos atrás, cando Fran e máis eu comezamos a falar de propiedade intelectual, xenéricos, software libre e desenvolvemento. Cómo cambiou o mundo anos despois: o software libre xa non é un descoñecido para o mundo da cooperación e os xenéricos pasan a ser unha realidade. Dalgún modo tamén éstos son os meus mortos. Choro por eles e déixoos ir. Agora, toca dedicarse ós vivos.

In recent times, the replicability of Software Engineering empirical studies has become a main concern in the research community. One way to achieve replicability is by reusing datasets, so everybody base their results on the same data. However, if these datasets contain any kind of problem, they could cause more harm than benefits.

In the case of software defects, there are datasets that are known to contain bias, mainly when referencing a fix to a particular bug report.

We have studied a different kind of bias: popularity bias. A software project with less bugs is of higher quality. However, in open source software development, more bugs may mean more quality. Why? Because more found bugs imply more people looking for those bugs. This is, if you have no bugs it is because nobody is using your software and reporting them. If you have more bugs, it is because your software is popular; should your software be less popular, the number of bugs would be lower. We have studied this effect in the case of Debian, using the Ultimate Debian Database, and we indeed find that only very popular Debian packages will present a very high number of bugs, and that non-popular packages get very few bug reports.

If you want to know more, read our WCRE 2011 paper, entitled "Impact of Installation Counts on Perceived Quality: A Case Study on Debian". A tag cloud of the contents of the paper:

To cite this paper, there is a BibTeX file available, or you can copy from below

@InProceedings{debian_wcre2011,
  author =       {Israel Herraiz and Emad Shihab and Thanh H.D. Nguyen and Ahmed E. Hassan},
  title =        {Impact of Installation Counts on Perceived Quality: A Case Study on {D}ebian},
  booktitle = {Proceedings of the 18th Working Conference on Reverse Engineering},
  year =         {2011},
  publisher = {IEEE Computer Society},
}

If you’re try­ing to make a suc­cess­ful tech prod­uct, 90% of the bat­tle is that it works at all.

Havoc Pennington, on creating a successful product… and companies I would add.

Parece ser que Mercé Molist está de vuelta. Y comienza publicando la historia del archivo que hackeó a la RSA israelí, el que a la postre, dió a los atacantes acceso a proveedores norteamericanos de defensa. Leyendo esto, uno se da cuenta de que Ghost in the shell ya no es ciencia-ficción futurista. No longer. Y se siente viejo.

En GHANDALF, la asociación para la difusión del software libre de la que soy cofundador, estamos estos días preparando un nuevo proyecto. Después de la estupenda acogida que tuvo la traducción al Gallego y posterior edición del libro Produccing Open Source Software en formato impreso, hemos decidio darnos esta vez un poco de autobombo y editar  un libro que recoja nuestros trabajos de la primera edición de Máster en Software Libre.

Recuperando esto días, aquellos maravaillosos escritos olvidados, llenos de ilusión, esfuerzo y falta de horas de sueño para entregar a tiempo, me he dado cuenta que en mi caso me vienen que ni pintados.

En gvSIG llevamos una temporada dándole vueltas a como integrar más a la comunidad en el proceso de desarrollo. Si bien mis trabajos no tienen la solución mágica a este problema, sí que daban algunas pinceladas que pueden ayudar a entender mejor como funcionan las comunidades de software libre. De uno de ellos rescato un breve párrafo que intentaba explicar brevemente como funciona el Onion Model. Si lo miras en la wikipedia probablemente lo entenderás mejor y hasta te vendrá un dibujo, pero yo pego aquí el intento que hacía para explicarlo:

“El Onion Model es un modelo característico de los proyectos de software libre y se cumple dentro de GNOME. De manera general, este modelo asume que el primer contacto con un proyecto de software libre se realiza a través de su página web, o como usuario del programa. A partir de aquí se puede utilizar la lista de correo del proyecto para consultar dudas e interactuar con otros miembros de la comunidad. Cuando se usa el programa se detectan errores, el siguiente paso es ayudar a la comunidad a resolverlos mediante el envio de informes de fallo. Para esto la mayoría de proyectos suelen usar una herramienta de seguimiento de errores, en el caso de GNOME se emplea Bugzilla. Cuando se tienen habilidades de programación se puede usar esta misma herramienta para enviar parches con soluciones para esos errores y así ganar méritos para ser incluido entre los desarrolladores del proyecto. Esto permite tener acceso directamente al sistema de control de versiones para subir las modificaciones directamente en lugar de enviar los parches.”

Esto es un modelo ideal, cada comunidad es un mundo y probablemente haya muchas formas distinas de hacercarse a ella. Conocer como funciona, como la gente se aproxima a tu proyecto, es fundamental para poder llevar a cabo una buena gestión de la comunidad y lograr esas preciadas colaboraciones que harán crecer tu proyecto.

Just found this online-ongoing comic by Sidney Padua created to the Ada Lovelace day in 2009. She depicts a steampunk alternative past where Charles Babagge and Ada Lovelace got to build the difference engine … to fight crime!! LOL. Here the chapters. Don’t miss this one: Lovelace and Babagge VS The economy, where they fight against the economic crisis of 1837, which has uncanny similarities to ours.

«And this is the essential broader point–as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria.»

Dhanji R. Prasanna (one of the engineers behind Google Wave), on how even the smartests fail to stick to the essential. Jointly with this other post, they both draw a good story for any startup to hear.

When trying to invoke a MeeGoTouch application's MSheet from a QML app, I was getting the following error:

There is no instance of MDeviceProfile. Please create MComponentData first.

Using MApplication instead of QApplication would solve that, but still a MApplicationWindow would be needed to make the MSheet appear.

After searching on Google for a while (see after the snippet for the sources) and talking to gri in #harmattan, I've come up with the following solution:

#include <MApplication>
#include <MApplicationWindow>
#include <MApplicationPage>
#include <QDeclarativeEngine>
#include <QGraphicsObject>
#include <QDeclarativeComponent>
#include <QDeclarativeContext>

int main(int argc, char *argv[])
{
    MApplication app(argc, argv);
    QDeclarativeEngine engine;

    // The context is unused in this example
//    QDeclarativeContext *context = engine.rootContext();

    MApplicationWindow window;
    window.showFullScreen();

    MApplicationPage page;
    page.setPannable(false);
    page.appear(MApplication::instance()->activeWindow());

    QDeclarativeComponent component(&engine, QUrl("qrc:/qml/main.qml"));
    QGraphicsObject *content = qobject_cast<QGraphicsObject*>(component.create());
    MWidget *centralWidget = new MWidget;
    content->setParentItem(centralWidget);
    page.setCentralWidget(centralWidget);

    int result = app.exec();

    delete centralWidget;

    return result;
}

From QML support in Meego touch Framework I learnt that I had to load the QML into a MeeGoTouch widget, so I followed Loading QML components from C++ to replace the loadQmlComponent non-existing method with the QDeclarativeComponent::create approach.

Also, note that I use MApplicationWindow::showFullScreen instead of MApplicationWindow::show and MWidget::setMinimumSize


• Images: on the left, the number of changes to the codebase (commits) agregated by year. On the right, the number of developers with at least 1 commit that year.
• Data: trunk from project repositories during the period 1999-2010.

Is it something we could extrapolate from the data there?

Certainly, not the number of features developed or bug fixes. It is even barely possible to compare activity between projects, as there are a high variability in terms of changesets: some people could send several little changesets and others just 1 big change, some project could have a special policy which affect the results (i.e.: make a commit formatting the code accoring to the style rules and other with the changes), etc. Some people could even argue that the language they are written in affects the number of changes (GRASS is written in C, gvSIG in Java and QGIS in C++) due to the libraries available or the semantics of every language. So, is it possible to find out something? Well, in my opinion, we can trace at least the following:

• the internal evolution of a project.
• how a project is doing in terms of adding new blood.

 So, let’s make again the exercise of finding out what’s happening here:

GRASS

• It calls the atention the curve of activity in the project: growth by periods (2001-2004 and 2005-2007) with local maximums in 2004 and 2007. Our hypothesis was that it was due to the way the project works: the developers here make changes both in the trunk and in the branch of the product to release (be it 6.4 or 6.5) at the same time, with a lot of changesets moved between both the trunk and the branches (so doing heavy backporting). In a recently conversation with Markus Neteler, he has explained me better how they work and I guess the rhythm we see in the graphics is due to that.
• In terms of number of developers, GRASS has showed a continuous growth until 2008; since then, the number of regular developers stabilizes.

gvSIG

• gvSIG shows an incredible high period of activity during 2006-2008 (4500 changesets by year and most that 30 people involved!). To understand the Gauss bell of activity, is needed to know the background of the project: gvSIG development has been led by contract, which means that all activities (planning, development, testing, etc) were led by the client needs who pay for it. Only recently, these processes have been opened to a broader community (firms and volunteers collaborating in the project within the gvSIG association). So, it makes sense that the beginnings had seen less activity (high phases of planing) and afterwards they got to agregate so many people in such a short period of time.
• But, in 2010 it suffered a sudden stop in development (only 233 changes to the codebase were made, while a pace of 4500 changes were made during previous years). This decreasing in activity is highly correlated to the number of developers involved. It’s hard to say why it happens: could it be due to the efforts were directed to gvSIG 2.0 development? could it be due to the reorganization in the project and the creation of gvSIG asociation? Well, few can we said at this respect with the data available, further research is required to determine that.

QGIS

I found interesting this serie of posts titled “4 big ideas in software development” according to Tim Ottinger and Jeff Langr. The serie was published monthly in Pragmatic programmers magazine:

• Code coupling, or Reducing dependency in your code.
• Cohesive software design, or Cohesion makes code easier to understand, debug, and test.
• Abstraction, or How to tell a cat from a dog.
• Software volatility, or Do most changes to your code base occur in just a few files?

Find below the statistics for mailinglist activity in GRASS, gvSIG and QGIS during the period 2008-2010. The first one shows data from the general user mailinglists for each project. Take into account that data for gvSIG agregated both international and spanish mailinglist due the reasons stated here.

The next one shows the same data (number of people writing and number of messages by month) for the developers mailinglists.

Is it something we could extrapolate from the data there?

Well, certainly not the user base. The data shyly introduce us the trends, not the real user base. The model we adopted to study the projects reflects just a part of the community -which is arguably the engine of project- but don’t take the data as the number of users for each project. For sure, each one of our favorite projects has more users than those participating in (these) mailinglists!

Anyway, here some food for thought:

• GRASS: it smoothly decreases in terms of number of messages as well as people writing, which happen within users and developers. The tendency is not clear though.
• gvSIG: the data shows a steadly increasing number of users participating in the mailinglists. On the other hand, although it is the project with more people suscribed to developer mailinglist, it shows the less activity of the three projects (in terms of # of messages in developer lists): few technical conversations seemed to happen through the mailinglists during that period.
• QGIS: according to the data, a clear growth exists in the community. In the period in study (3 years) the number of users and developers participating in mailinglists has been doubled!

«Colocar hoy quinientos millones de acciones del Banco de NCG, sin malvender a precio de saldo, no es realista. Es como poner en estos tiempos a la venta un piso y que se sepa que necesitamos el dinero en seis meses. Por eso se habla ya de descuentos por encima del 50 %.»

Albino Prada, sobre la (mal)venta de las cajas. Léase con su contrapunto: “Loterías no sale a bolsa porque sería malvenderla“.

No os perdáis esta experiencia de gobierno en Lower Merion, una ciudad de 60.000 habitantes a las afuera de Philly: sin alcaldes se vive mejor.

The International Journal of Social and Organizational Dynamics in Information Technology (IJSODIT) calls for papers for its 2012 issues.

The mission of this journal relates to social issues in information technology. Social issues are those research topics most aligned with the human factor in terms of information systems planning, development and utilization. This journal includes all aspects of social issues that are impacted by information technology affecting organizations and interorganizational structures. This includes the conceptualization of specific social issues and their associated constructs, proposed designs and infrastructures, empirical validation of social models, and case studies illustrating socialization success and failures. Some key topics may include:

1. Ethics
2. Culture
3. Relationships
4. Human interaction
5. Security
6. Design
7. Building relationships
8. Diversity in the IT workforce

This journal follows a full blind peer review process.

More details about the call for papers.

Within gvSIG design, MapControl is one of the core components. Its main responsibility is to allow users to interact with a map of layers (zoom in/out, edit geometries, …). That goal is achieved through two concrete tasks:

• Route the user actions to the proper tool which will execute it.
• Manage the drawing of the layers.

This post covers the first of above tasks in an introductory way.

Flow of control

MapControl is a java component, which uses the idea of Chain of Responsibility to delegate work on others. Let’s see how it works in this case with a good old graphic:

1. MapControl listen MouseEvents through the MapToolListener. In response to an event, the MapToolListener will call the active tool (let’s say this class is named Behaviour).
2. The active Behaviour processes the info from the mouse, put together the contextual information needed (let’s call that an Event) and calls the next step in the chain (let’s call it the ToolListener).
3. Finally, the ToolListener will execute the actions needed to carry on the task an user have asked for.

public void mouseReleased(MouseEvent e) {

    try {

        if (currentMapTool != null)

        currentMapTool.mouseReleased(e);

    } catch (BehaviorException t) {

        throwException(t);

    }

}

public void mouseReleased(MouseEvent e) throws BehaviorException {

    if (e.getButton() == MouseEvent.BUTTON1 && m_FirstPoint!=null) {

        MoveEvent event = new MoveEvent(m_FirstPoint, e.getPoint(), e);

        listener.move(event);

    }

    m_FirstPoint = null;

}

public void move(MoveEvent event) {



    ViewPort vp = mapControl.getMapContext().getViewPort();

    Point2D from = vp.toMapPoint(event.getFrom());

    Point2D to = vp.toMapPoint(event.getTo());



    //build the new extent

    Rectangle2D.Double r = new Rectangle2D.Double();

    Rectangle2D extent = vp.getExtent();

    r.x = extent.getX() - (to.getX() - from.getX());

    r.y = extent.getY() - (to.getY() - from.getY());

    r.width = extent.getWidth();

    r.height = extent.getHeight();



    //update the ViewPort

    vp.setExtent(r);

}

Some useful resources about MapControl in gvSIG wiki:

• MapControl (spanish)
• Behaviour (spanish)
• ToolListeners (spanish)
• Events related to toollisteners (spanish)

• Mapcontrol
• Canonical events of MapControl:
• MeasureEvent
• MoveEvent
• PointEvent
• RectangleEvent

When selecting an aplication, it’s very common to weight tecnological factors -what the aplication enable us to do?- and economic ones -how money do we need?. And yet, there is a third factor to take into account, the social aspects of the project: the community of users and developers who support it and make it be alive.

During a serie of posts begin with this, I’m going to show a quantitative analysis of communities from 3 reference projects in GIS arena: GRASS, gvSIG y QGIS. We selected those, as they are viewed as the more mature projects in desktop GIS, they are under OSGEO Fundation umbrella and show some differences on the actors who bootstrapped and manage today.

What we have done?

During the more than 25 years of free software movement, it has delighted us with the high capacity for fostering creation and innovation a community-based model has. Along last years, that model proved its viability in other areas too: content creation (wikipedia), cartographic data creation (openstreetmaps), translating books, etc. Yet, few is known on “how to bootstrap and grow a community”. The only thing we can do is observing what others have done and learn from their experience.

In order to contribute to the understanding on how a community-based project works I’ve work with Francisco Puga and other people from Cartolab to put together some of the public information the projects generate and make some sense from that. The actors in a community interact with each other, and, when that happen through internet, a trail is left (messages to mailinglists have author information and date, code version systems log information about the authors too, …). Basing our work on this available and public information -and standing on the shoulder on giants -i.e: reviewing a lot of research works similar to what we like to build- we have developed a quantitative analysis on the communities supporting GRASS, gvSIG and QGIS.

How did we make it?

The first step was to evaluate and gather all the public information a project, for what we like to do it in automated way. But, as we had to compare the 3 projects, the data had to be homogeneous: at least exists in both 3 and be in a comparable format. Taking these constraints into account (and the limited time we had for this!) we have collected information from 2 different systems:

• Code versions control systems: from every project, we cloned all information available in their repositories to a local git repo, in order to parse the log of changes. This allowed us to study all the history of projects, from the very begining to December 2010.
• Data was got from trunk: grass - gvsig - qgis.
• Mailinglists: by means of mailingliststats tool -built mainly by our friend Israel Herráiz, thanks bro!- we gather data from March 2008 to December 2010.
  • Development mailinglists: grass - gvsig - qgis
  • Users mailinglists: grass - gvsig en / gvsig es - qgis

Some disclaimers:

• Projects have a number of branches, plugins and so. We focused the study on the main product, what an user get when she downloads it. Further study on the plugins ecosystem is needed, and it will give us more fine-tuning information.
• Projects have a number of mailinglists more than we have studied (translators, steering committee, other local/regional mailinglists, etc), varying on each case. The analysis was focused on developers and users ones due to we think they are representative enough to mark the trend. We are not interested in giving an exact number (which may be impossible to measure!) but in drawing the long-term fluctuation of participation. Our intuition and past experiences, says that those mailinglists will follow a correlation of participation with the larger community surrounding the projects.
• In the particular case of gvSIG users mailinglists, we have studied spanish and english mailinglist jointly. It makes sense doing so as the spanish mailinglist still have the core of contributions from hispanoamerican countries and non-spanish people interacts through international mailinglist. It is like the project have two hearts.
• Unfortunately, quality of data have limited the period in study: the range is from March 2008 to December 2010. Prior to that, not all projects have information due to mailinglist migrations.

What is it useful for?

It’s possible to analyze a community from a variety of points of view. Our approach is a quantitative focus by means of a common model which agregate users depending on their level of participation:

• Leaders: those who build the product and make the decisions.
• Power users: those who adapt it to their needs and using it intensively.
• Casual users: those who using it for a concrete task.

This approach allow us to better understand the size of the community and how they interact, as it’s not the same the value provided by someone who in 6 months only sent 1 mail to a mailinglist than other person who spent that time sending more than 100 patches to the code.

With these constraints, we managed to built the following indicators:

• Adoption trend within users and developers: based on mailinglists data.
• Status: post published.
• Activity and manpower: based on code contributions (commits).
• Status: post published.
• Composition of the community: based on code contributions (commits).
• Status: still to be published.
• Generational analysis: based on code contributions (commits).
• Status: still to be published.

During next weeks, I will be publishing the results of the study, in order to help us to understand how different free software communities work, and what we can learn from that. Stay tunned!

Coda

The results shown here are borrowed from a paper I led jointly with Francisco Puga, Alberto Varela and Adrián Eirís from Cartolab, a GIS university research laboratory based on A Coruña. The results were shown on the V Jornadas de SIG Libre, Girona 2010. If you are fluent in spanish (reading or listening), you can benefit from these resources:

• (in spanish) The complete paper [PDF].
• (in spanish) The slides [PDF].
• (in spanish) Video explaining the highlights - not my best performance though

Done some reorganization on wiki contents and wrote a bit on refactoring and code smells. I’m proud on the pace and themes the wiki is evolving: I have grown quite a bit of software development topics, which is a reflection on my readings and focus last years. Although could evolve later, the topics on software development are organized in 3 subcategories:

• History of software development: remember to build your products on top of giant’s shoulders.
• A programmer toolbox: common knowledge a developer should know. Items focus on programming and code.
• Project management: issues to take into account when managing a software development project: from concept to cash. Mainly not related to code.

«I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.»

Automattic Creed, the values on which Automattic bases its roots on.

I’m a longer passionate on community-oriented products: I’ve researched on how they work, have led one to their goal and participate in some. It’s not a new story what they are considered a powerful way to build your products (sometimes, a better one than doing in through the market or internally in a firm/closed-group-of-people). Nevertheless, I’m still looking for some good resources to learn more. For those who like the topic, find here someones I found useful (and I’d like hearing your recommendations!):

• Producing Open Source Software: the best book I’ve read on how to manage free software projects. Not only a good review on several tools, but also take into account the policies, what gives sense and glue together the community. Very practical.
• Coase’s Penguin, or Linux and the nature of the firm, by Yochai Benkler. The best academic text I’ve ever red on the matter. Benkler tries to explain why in S-XXI communities emerge as a new way to build products. You will find parallelism to the text where Coase explained why firms emerged in the S-XIX and replace local markets as preferred option. I think some more work is needed to formalized this concept in the academic arena, but the paper is clear, understandable and put the basis to further research. It’s a pioneer.
• Community antipatterns: a good talk by Dave Neary. Although it’s also focused on software development, I think it has lessons for broad communities. Sometimes, and much more in recently discovered fields, we have no idea what have worked, but know what have no worked.
• Other’s experiences. Particulary, I’ve found very useful these texts:
• Contribute/BestPractices, by Mozilla.
• How wikipedia works.
• Others I can’t remember now.

After having improved the movie showtimes support and updated the UI so it aligns better with the Swipe UX, this Saturday I submitted Butaca to the Ovi Store. Yesterday (yes, that quickly!) I got a notification that it had been accepted. I'm really satisfied with this release: I use the application myself a lot, and it's great to be able to check which movies are playing on the cinemas and later review their details and the crew's.

Searching movie showtimes

I've uploaded a screencast to Youtube, displaying how the application works, and -as usual- screenshots are available at my Flickr gallery. You can also review the release details at the project page (where you'll be able to file bugs or get support as well).

If you wonder what's to come next, here's some insight:

• Localization
• Check for extras after and during the credits (now that I have an API available for that)
• Offline mode / better data caching
• Embed trailer playback in the application
• UI improvements

Download Butaca for free from the Ovi Store!

Imagina el siguiente caso: deseas usar una aplicación que es software libre para construir tu propia solución ad-hoc sobre ella. Y lo harás muchas veces para diferentes clientes/productos. ¿Cómo enfocarlo? ¿Construyes tu solución con tus mejoras para ti modificando lo necesario o integras tus mejoras en la versión upstream, en el proyecto original?

Si ése es tu caso, te recomiendo que leas estos 2 artículos. El primero se centra en los aspectos económicos y sociales, el segundo en los técnicos y sociales:

• The cost of going it alone, de Dave Neary. Un buen repaso histórico con casos como el de  Softway con GCC (cambios relacionados con Windows NT), Nokia con GNOME (cambios relacionados con Maemo) o Google e IBM con el kernel (el primero por cambios en Android, el segundo por cambios relacionados con drivers para manejar discos virtuales).
• Working with upstream: an interview with Laszlo Peter, by Stormy Peters. Laszlo Peter era release engineer en Sun, es decir, quien se tenía que preocupar de que en cada nueva release de Solaris todo fuese bien.

This month, the IEEE Software magazine comes with an interesting article about the impact and possibilities of different open source licenses on business models. The paper is available at the IEEE Digital library: Matching Open Source Software Licenses with Corresponding Business Models. From the abstract:

Scores of software producers have turned toward open source licenses
to improve service for their customers. For these companies, choosing
the correct license determines business success. When the available
open source stack and licensing options grow, so does the need to
understand the interplay among licensing, sourcing decisions, and
business goals. A model of license choice emphasizes different
licenses and rationalizes the choice of an open source software (OSS)
license. This is crucial for smaller companies and start-ups that
don't have the tools and knowledge to perform a thorough investigation
of all the consequences of their license choice every time they employ
OSS.

Furthermore, the Computer magazine also brings an interesting article about how to manage open source projects, from a point of view of a software firm. It is also available in the IEEE Digital library: Controlling and Steering Open Source Projects.

Please bear in mind that the IEEE Digital library is a paywall. Send me a message if you want to have a look; I can send you a copy if you cannot access the papers.

I’m not such a fan of comparatives to rank things. But I find them useful to know your pros and cons, or at least to know how the surrounding community perceive your product. While having a coffee today I found this article on gis @ stackexchange: QGIS and gvSIG comparison. Made me happy than 2 out of 6 gvSIG pros are tools where I’m engaged: NavTable and OpenCADTools. Keep rocking cartolab and iCarto!

¿Qué hacer cuando el modelo organizativo que te provee el estado de bienestar (educación, sanidad, trabajo, etc) no funciona? La idea de que las naciones han sido superadas como organización para garanizar el bienestar la tengo superada hace tiempo. No por ello es menos doloroso cuando lo sufres en lo que antiguamente consideraste como algo similar a una casa. ¿Qué hacer pues? ¿Con qué parte quedarse en la revisión del viejo debate?: estados fuertes (socialismo de estado) VS capitalismo de amigotes (capitalismo laisezz-faire). Me parece que toca releer y recuperar a los mutualistas, a los socialistas libertarios.

«It may be impossible to despise your client or users and still deliver a quality product.»

A good story on leading by example by Avdi Grimm. On why code quality matters.