Monday, January 19, 2009

Open-source seem to be a good candidate for the next round of tech-related hype (just after the dotcoms and web2.0). Ideas which have been implemented more or less quietly by a bunch of enthusiasts (like Wikipedia, for example) are already cloned (Google's Knols) - open-source is a philosophy which allows to grab the ideas of others and reimplement them, as long as you don't forget to mention the original authors (if they can still be traceable)...

Several things which I can't help noticing:

1. I can't understand how the old patent system and open-source approach to the copyright are going to coexist together. For example, Google is now actively promoting their new mobile phone, Android, and encourages young, enthusiastic and (often) not-well-paid-yet guys and girls to write new, exiting, and no doubt, open-source applications to promote Android even further (the best ones are getting the blue ribbons indeed). What about the patents for these ideas? Who is going to hold them at the end? These guys (I have asked one of these winners at the Android Developer's camp in Amsterdam) seem to never think about this.

2. What about the data? Who owns the data collected by Wikipedia? Who owns the data collected by e.g. TomTom (my previous employer) via MapShare technology? Who owns the data collected by OCLC (my current employer) via WorldCat? (This one is actually the flamebait right now, the other two have not been discussed, or I don't know about it). Who owns the data collected by Google via their system of blogs (like this one :) ), webmail, etc? Is it possible to talk about the data ownership in this case, or only about the ownership of the data maintenance structures and the right to use the data because of that?

2a. Don't forget, "data maintenance" should include data verification and systematizing, which is not the work for novices and requires quite a strong discipline, like every necessary routine . It also implies guaranteed all-time access to the data (which means hardware issues), and these parts are not that easy to open-source. Distributed computing is one of the answers to that, but the payoff is performance. If the responce time is supposed to be critical, then you need to have some dedicated hardware and it has to be supported, therefore somebody is supposed to get paid for it.

3. Open-source, in itself, is not a silver bullet. If you compare an open-source solution and a closed-source one from the point of actual costs you spend to get what you want, the result might be quite surprising: fixed costs for closed-source solution (price of the software + maintenance costs, which is usually agreed upon beforehand) versus open costs (nothing + salary of the guy or guys who are going to support this piece of software for you).

4. Software is not good or bad because it is open- or closed-source. It is good when:
- it is clearly documented;
- it is well tested;
- it is well supported;
- it is written well.

All of this can go wrong for open-source project as well as for closed-source one, but in the case of open-source project, if you happen to be the client and the project dies, you are left with nothing because nobody has been responsible. The documentation is not the thing programmers like to do; you won't find much documentation even for Mozilla (one of the longest and extremely popular open-source projects). The wider scope the open-source project has, the more important becomes the question of organizing the "crowdforce"; it is more difficult than to order around guys who are reporting to you because, after all, these enthusiastic guys and gals work for fun!.. If you spoil the fun, they'll go!

5. The term "crowdsourcing", to be honest, makes me remember the work of José Ortega y Gasset called, in English, "The Revolt of the Masses". The point of this work is that unorganized masses are actually the reactionist force. The crowd, if not organized, is less smart than any single member of it. What is needed for open-source project to succeed is the organized crowd, so that it really becomes the whole where various parts play various roles for the common good. If the project leaders manage to achieve and keep this state, good for them. If they also know what they want to achieve with their project and can share their vision with their team and get their support in return, excellent. That is how it should be. But there is no guarantee that it will always be like that.

6. "The human factor" becomes extremely important. People have emotions. You never know what makes the other one explode until you are swooshed away by the blast. If the project becomes big enough (on the order of several dozens of active participants) the conflicts will be inevitable. The project leader has to be prepared to solve them, sometimes by force, and to have enough self-confidence, so that the others would not question every decision he makes. This is a tough part.

7. Finally, the disclaimer: I am quite enthusiastic about the open-source approach, but that is why I can't stop thinking about the ways how it can fail. It would be a real pity if open source, as a result of the coming hype, becomes an "anti-buzzword", like these dotcoms of the past century.

Update: Open-source has its charms, there is no doubt about it. It allows the developers to become experts in the areas they like, and to stay experts no matter what their official affiliation is. It makes the workforce more mobile, because your expertise with (the development of) open-source products is often easier to take along to the next assignment than the expertise with (the development of) closed-source products. Therefore, it makes the work for the developers look more like hobby, which is good for the morale. That is why it is so important to make sure that open-source initiative, now that it came into open light, will stay healthy.

No comments: