Software adaptation, deployment and sustainability

Last May 23rd I went to the ceremony for the end of academic course at MSWL (Master en Software Libre, BTW inscription is open at URJC), where Jorge Ferrer from Liferay gave us a great talk about developing and deploying libre software and its related business models. He talked from a very practical perspective, based in his professional career and experience. I liked it.

One of his taughts that called my attention was his advice about the need of think well before forking/adapting a libre software project, since you (your company) can create what he called a “frankenstein” (specially when you begin in this business): based on customer requirements, you start from an existent free software project, and begin to change things here and there, and deploy your derived work  to the customer. Later, a new release of the original work (upstream) comes to the market, and the customer asks for update or deploying that new features; but it is not possible anymore (or takes a huge work) because the project you had deployed has diverged too much from upstream and it is necessary a long-time, high-cost migration.

I saw myself (my office) reflected in that idea. We are stuck at job with a modified version of PHPScheduleIt 1.2.8, while upstream project released version 2.1.14 few weeks ago, and a website based on Drupal 5 with some in-house modules, written by a person that is not working here anymore, and current development team (me too) overloaded with new services and features to develop in other sites.

So with these examples we face a paradox (in libre software world there are many of it!): free software licenses allow you to modify the source code (and it is a strong temptation as soon as you find a software that is “almost what I was looking for”) but you (and anybody) should think twice before “just doing it”. It does not mean “don’t do it”, but it would be desirable to take some aspects into account (sorry, you will find my personal view of what Jorge Ferrer explained, don’t blame him if something is not correct or you don’t agree!):

  • Just after development, testing and deployment, it comes the maintenance phase, which can be very long in time and very resource-hungry. The more than you “diverge” from upstream project, the more you (and nobody else) will need to invest resources in maintenance.
  • So keep track of your changes because if you chose a good, lively project, new releases will come soon or later, with new features, security updates etc and you will need to look at that new product and your instance of the old product, and how they can be merged.
  • Try to commit upstream as much changes as you can, so you can benefit from the whole community caring about those changes. This applies for example to bugfixes, internationalization, translations, documentation… everything that you can imagine. So it is important to keep in mind your customer’s needs, but also tailor your tweaks in a way that the whole community of the software project can benefit.
  • Above said also applies to design changes: if you are part of the upstream project as a good contributor, your ideas will be more welcome and maybe your proposals (customer needs) are accepted (and the upstream projects fulfills your needs, avoiding the fork). But you cannot premeditate this, if you do it, probably things will go wrong for you, because nobody likes to be “used”. However, libre software world is generous and when you give something, you always obtain something (or many things!). It’s a matter of trust (or faith?), and the art of stablishing symbiotic relationships (not parasite!).
  • If you survive in this free software business, and your project gets big or you become part of a big project, you will meet other people doing “frankensteins” here and there. You may begin to look at them as “they“, “the people against us”, the people that do not contribute upstream, the people that spread a bad image about the upstream project with their poor deployments. Try to avoid that thoughts. They are in their right! It is one of the richness of free software: only allowing this “diversity” is the way that great things are born. And in addition to this, don’t forget that you were like that once upon a time… We are learning all the time with each other, and in the long term, the good models (more efficient, better quality, more flexible) survive. Again a matter of trust (yourself, your work…). Or at least, you can look at the work that you did, and feel proud of it.

I have little experience using and contributing to libre software, and I’ve never developed/deployed libre software in a business environment (my job is in a public educative institution, and I am more like a sysadmin than a developer). However, I liked very much to listen and think about all these things, since the role of companies in libre software is more important each day. In addition to this, I liked to feel that many things that Jorge said we had already studied in several subjects in the Master on Libre Software (Economic Aspects, and Project Management for example), so it was a kind of proof that the studied concepts and ideas apply “in the real world”.

I would like to know more experiences about this topic: forks, adaptations, deployments, companies doing business with libre software. Writing this I opened the conversation. What do you think?

About larjona

My name is Laura Arjona, I am a libre software user and fan of the free culture. If you want to contact me you can write an email to larjona [at] larjona [dot] net I am @larjona at identi.ca in the Pump.io social network. --- Me llamo Laura Arjona, soy usuaria de software libre y fan de la cultura libre. Si quieres contactar conmigo puedes escribir a larjona [en] larjona [punto] net Soy @larjona en el servidor identi.ca, de la red social Pump.io.
This entry was posted in My experiences and opinion and tagged , , , , , , , , , , , . Bookmark the permalink.