What is wrong with the GPL?

Many times I have been asked why I didn't choose to put my source code under GPL.

Now here is why.

First though, a disclaimer, many people have discussed whether or not the GPL is a good or bad thing. I personally think there isn't anything good or bad without a clear definition of the context in which this tags are being used. Just see what Webster tells us for the noun good:

1 a : something that is good b (1) : something conforming to the moral order of the universe (2) : praiseworthy character

I don't know about you, but for me "the moral order of the universe" is something pretty fuzzy:

2 : lacking in clarity or definition

So, what follows isn't about marking the GPL as good or bad, it's rather my reason why I don't want to use it.

Reason
1a: a statement offered in explanation or justification
b : a rational ground or motive
c : a sufficient ground of explanation or of logical defense; especially something (as a principle or law) that supports a conclusion or explains a fact
d : the thing that makes some fact intelligible

Richard Stallman calls the GPL pragmatic idealism. Now, allthough from my point of view these two words are pretty close to an oxymoron, I probably need to read up on it in one of Nicolas Rescher's books ("A System of Pragmatic Idealism" Vol. I and II).

Let's see what is the pragmatic and what is the idealistic part.

Idealistic is the notion of freedom.

The free software definition states the following:

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

• The freedom to run the program, for any purpose (freedom 0).


• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  
• The freedom to redistribute copies so you can help your neighbor (freedom 2).


• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

Now, this isn't something particular to the GPL, but is shared by many other licenses as well.

Pragmatic is the notion of copyleft.

Which basically is described as

..a general method for making a program or other work free, and requiring all modified and extended versions of the program to be free as well.

And here is where I see the big catch with the GPL: the above is an euphenism for the fact that the whole idea of freedom did not seem practically viable to the author of the GPL, or
Freedom comes at the cost of freedom?!

Sounds a lot like the purpose sanctifies the means to me. Religious, not pragmatic at all.

Additionally the only real argument given by Richard Stallman's Copyleft: Pragmatic Idealism is simply the fact that it was effective. E.g. it produced the initially desired effect:

If you want to accomplish something in the world, idealism is not enough--you need to choose a method that works to achieve the goal.
[...]
GNU GPL continues to bring us more free software
[...]

I think that freedom comes at the cost of responsibility, and I am definately not the only one:

Responsibility is the price of freedom.
(Elbert Hubbard)

Liberty means responsibility. That is why most men dread it.
(George Bernard Shaw)

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
(Benjamin Franklin)

The very best counter argument to the GPL's effectivity is the Apache License of the Apache Foundation.

Let's all grow up and become more conscious. Not by force, but by free will. Including all those that "pirate" our software.

Just being (hu-)man

I finished watching Closer.
She is just beautiful.


(That's a small wallpaper for a mobile phone)

Uuuuuuuups and pheeew!

Today hasn't been one of the best days. Sometimes things just go wrong, especially when you least need them to go wrong. Now, it's not just that I wanted to share a picture of my desktop (see left), but rather the fact that I am doing an emergency backup of my Powerbook internal harddisk, because the computer literally (physically) crashed today (see bumps below).



I was pretty lucky though, because no vital parts were affected by this accident. Nonetheless, I had to disassemble my PB (see below) and fix it up a bit. At this point a huge thank you goes to former PBFixIt (now iFixIt), their guides are really well done and help to safely disassemble and reassemble a large number of Mac laptops. You have saved me and friends of mine more than once in my history with Mac laptop computers.



The chain of bad luck with this specific computer does not seem to end:

1. The mainboard was replaced, due to a problem with the
   Memory Slot


2. The screen was replaced, due to a problem with white spots. This problem is occurring again (see below), but that's the only computer I have and here in Mx, repair means at least two weeks without a computer.
   
   


3. The battery had a serial in the range 3K425-3K601, so it needed to be replaced as well (three weeks no battery).

I am still trying to raise funds for a new machine. You may ask why Apple, but my answer is that I'll give them one more chance, because with OS X (and it's underlying UNIX) it's just the most productive environment for all that I do.

Some things ten years of open source development have taught me

I was reading this top-ten list and I thought I can probably come up with my own little list of things I learned in ten years of developing open source software. This is my list:

1. Write less code and more documentation.
Whether you want people to use your software, or other developers to join in, the more you document your projects, the easier it will be for others to figure out what to do with them or how to extend them and contribute back.
I know it is a pain in the ass, but it's worth the effort when you have suddenly some people helping you out or cheering you up, because your documentation triggered the "ah, that's how it works" effect.

2. Communication is indeed the most difficult part.
I'd take it a little bit further though then Andres, it's not just soft skills, but also work on being conscious, tolerant and patient. Always remember:
a) eMail isn't the best and easiest way to communicate
b) People that write to you may hardly speak the language they used for the message
c) You may have received the same question many times, but for the other end it's a first. (Consider investing time in an FAQ if it repeats too often.)

Point out what might help people to solve their problem (see 1. Documentation), rather than trying to solve it all for them. Also, consider the use of alternative channels for communication (like Instant Messaging services), probably even invite developers to join for a real-life meeting. Also see 3.

3. Write code with style.

The syntax of a programming language tells you what code it is possible to write - what the machine will understand. Style tells you what you ought to write - what the human reading the code will understand. Code written with a consistent, simple style will be maintainable, robust, and contain fewer bugs.

(from "The Elements of Java Style", Vermeulen et.al., at Amazon)
I carry this little book practically everywhere.

4. Simple is beautiful.
"Make everything as simple as possible, but not simpler."
(Quote attributed to Albert Einstein)
KISS isn't quite the same, I for my part don't like things or people to be considered "stupid". Simple means also elegant, e.g. don't over-design and don't under-implement. The devil is always in the detail (which is an old german proverb).

5. Try to find a good balance between implementing yourself and adding dependencies.
You can't write everything on your own. Sometimes it is better to spend a little time to figure out if some external library may solve your problems, probably with a little bit of enhancement (try to contribute it back to the mainstream; also see 9.).
On the other hand too much libraries makes things harder for maintenance.
Try to find a good balance, or you end up with either writing too much code that reinvents the wheel, or too much libraries you have to track to be sure that everything is running smoothly.

6. You can't make everybody love it.
There will always be some people that are convinced that something else is better, because your project doesn't do a, or b or c.
No matter how much you try to explain that it doesn't make sense, they won't change their mind. My experience is, that if they are willing to contribute and enhance it, then take it seriously, if not, then ignore it.
Open Source software isn't a commercial product, but even if it would be, to endlessly add features isn't an answer, as Japanese car makers had to learn the hard way.

7. At the beginning, it is not just about selecting a license, also think about the decision making process.
Usually people think it is all about the license. I think that Apache is successful, because they have project guidelines and a well defined decision making process. This seems superfluous at the beginning when you are few (see 8.), but it may help the project to survive steady growth (also in numbers of developers).

8. Meritocracy is great, but it has some flaws.
a) It simply doesn't work when you are initiating a project, that's why they invented the incubation at Apache.
b) Don't underestimate the power of one-time unsolicited contributions.
c) Don't over-bureaucratize the decision making process, software development is a creative process.

9. Learn about licenses, copyrights and contributor agreements.
All this legal stuff is boring for the average developer. Nonetheless, if you are managing a project that is completely exposed publicly, learn how to protect your project and its developers from legal traps.

a) Netiquette: try to be kind and make clear how to be so. Sometimes we programmers like to channel our desperation into code comments, but it isn't such a good thing if certain offensive expressions end up in the code repository.

b) Licenses
Some licenses cannot be mixed, like GPL and Apache don't work together (LGPL does for some use cases). Understand what implications the license has, and make sure to pick and know the licenses of your libraries to fit with the one you use for your own work.

c) Contributor Agreements
Commitment is about trust and responsibility. Protect your project and your developers with individual and corporate contributor agreements. These agreements are not about taking rights from the developers, they are about the developers giving certain (usage) rights for their code to the particular project, otherwise completely reserving their right, title and interest.

10. Make friends, they may last for the rest of your life, projects are always time limited by definition.
While you are at it, make friends with fellow developers or contributors, or users. Not everything happens in the virtual world, bringing it to real life will greatly enhance relationships and communications. We are, by all means, human beings. We all make mistakes, we have good and bad days and we can always learn from each other in many dimensions, not just professionally by sharing code or documentation.

OS Project Feature: jamod

Open source is sometimes really fun, if you manage to handle levels of abstraction (I recommend reading some of Alfred Korzybski's work), and you always assume that people don't read manuals or readme documents (if available). When dealing with people's inquiries, it always comes down to patience....

A living example for jamod is:

I have already looked at http://jamod.sourceforge.net but cannot see the relation between Modbus protocol and Java implementation. thanks!!!

I always thought the relation was quite clear: jamod is an implementation of the modbus protocol in Java.

jamod is actually pretty well documented for an OS project, because I initiated this project during my master thesis at the Institute for Automation, University of Leoben, Austria.

If you don't know anything about modbus then you may get started reading the documents in the Knowledge Base. I specifically recommend the one that describes the protocol.

Now, there it says:

At this level Modbus is a stateless client-server protocol (e.g. much like HTTP), based on transactions, which consist of a request (issued by the client) and a response (issued by the server).

They keywords in this quote are transaction, request and response. Funny enough OO allows for a direct representation:

1. ModbusTransaction


2. ModbusRequest


3. ModbusResponse

The rest follows logically, in levels of abstraction. Requests and responses are both messages at a more abstract level, and there are specific requests and responses for modbus functions at a less abstract level. Things do fall in place and suddenly there is a very clear relationship between jamod and the Modbus protocol.......

And then, this is also a little bit what the various How-To documents are trying to transport to their readers. Actually they take you step by step through an example, as can be seen here.

Additionally, for those that find using jamod as OO library too complicated, there is still the option of using a facade pattern class, which you can find in the net.wimpi.modbus.facade package.

At other times, the questions about using jamod are more about the lack of Java knowledge:

Can You help me how to import/introduce java modbus library in to my java code, I would thank you about!

Now, I always suggest the excellent and online Java Tutorial. Also, there is a reason why I put a Target Audience section on the first page of each of my projects, in the case of jamod:

Java developers which need to access or share data using Modbus protocols.

I am tempted to give a free unsolicited career advice: don't call yourself a Java Developer until you know what a JAR is and how to use it. I don't say you need a certification, but at least try to figure out the basics on your own :)

Allthough, there is still an option to even avoid most of the Java side when using jamod, namely, compile it to a native library using gcj. This opens a range of possibilities when you don't want to have a JVM in first place. On the other hand, jamod also has been compiled for and ran on TINI and SNAP, embedded internet enabled platforms that may be interesting for some automatisation applications. Last but not least, jamod has also been used to talk to Industrial equipment, like the Beckhoff BK9000 Remote I/O Coupler.

It is as versatile as Open Source may be and usually when people understand the levels of abstractions and the ideas behind them, they manage to use jamod easily in their projects and products.

Collecting for a MacBook Pro

Being a student, financing new hardware is sometimes difficult. All my open source work depends on me having a useful portable computer (I move around a lot), so I want to try to collect for a new one, that will help me to continue working on various of my OS projects.

If you have made good use of some of my code, I invite you to participate.
A special invitation goes to those that are making money from this use:

• Sun Microsystems: You are selling my software as part of your StorEdge product.


• Cisco: You are selling my software as part of your EDI product.

With best regards and thanks to all that contribute,
Dieter

Orion, night sky over Mexico City

Photowalk Insurgentes

Today I have been photowalking along a part of Insurgentes, specifically from the Metrobus Station Dr. Gálvez to the Station Buenavista (buenavista, buenavista, buenavista); see below, and to the left you can see the hybrid map of the geolocated photos in Flickr.


It lasted around 5 hours from 09:00 in the morning until 14:00, including a small coffee break :) I had wonderful company and aid with the selection of photos (101 out of 221) by Alba, whom I made to do about the same job as usual but on the weekend. Some of my favorites are:

• Beatle Taxi


• Sun relfected in the upper corner of a building


• Building reflected


• Nortel Networks Building (skyscraping)


• Sun reflected from a building


• Shoe cleaner reading the newspaper


• Jacaranda


• Reflection and composition


• Building with trees on top and plane flying over


• "Small" business


• Street Dog, asleep in the middle of the humming city life


• Luis Pasteur with reflection

You can find the complete set here.

Enjoy!

Photowalk UNAM

A photowalk through a part of the Universidad Nacional Autonoma de México (UNAM), my second almer mater.
Enjoy!

Google lost in translation?

I think there is this one experience I'd like to share; if you adore Google, read on.

After spending a long time on education and working aside of it to finance the whole idea, I wondered whether I should try and apply for a job. So, one sets out and tries to figure out how to get one.

(Author's note: Right. At some moment in time one needs to realize that it isn't economically feasible writing code and designing architectures for Open Source alone, at least if you aren't employed).

First stop along the road is collecting your "experience assets" into a resume.
In English, certainly.
Now, let's see, probably these ten (10) years of Java hands-on Java experience, doing some really nice Open Source and commercial stuff can be considered as such. Last but not least some companies like Sun, Cisco and Atos Origin even dropped some of the OS code into their products.

Next stop is about dropping off your resume for a nice Job, so somebody reads it and invites you to an interview.

(Author's note: Is it really just me that would like to search for the right type of job first and then decide the location?)

So who might be an interesting employer? Hmm, probably Google. they are looking for a lot of people....right. Nice jobs down the road, probably an idea for the next stop.

(Author drops the resume in Google Mailbox; automatical answer arrives and he feels at ease, everything is fine.)

Some days pass and then a mail from Google appears in the Inbox.

(Author's thinks "Wow, quick..." and reads on....eyes wide open...)

We received your application for the job entitled '....'.  
However, this job requires that you include an English resume. 
Please resubmit your application with an English resume.

(Author panics and checks his resume, starts to read the letter of presentation....summarized:)

I want to introduce myself as creative and interdisciplinary
engineering graduate with technical, methodical and social
competence, which I acquired over the time through
education, professional and extracurricular activities.

(Author wonders.)

So far so good. Probably they are not interested.

(Ok, why not tell it straightforward?)

They want to express that the English you used isn't good enough.

(Author's thought: Yeah, it's not my native language, but well, it's English anyway.)

Google messed up.

(Author's thought: How they heck do they manage to index billions of pages and mess up with applications that come in thousands?)

You tell me.

Ah right, sorry, you only speak English, so you never found this using Google and you couldn't read all of the above anyway.

Blog

I have decided to revive my personal blog to rant on a little bit about what I am doing. Generation N needs to be wired ;)