Nick Vlad

From Madagascar
Jump to navigation Jump to search

Please tell us about yourself

I grew up in Communist Romania, which for all practical purposes it was a timewarp into the 1950's. The good things to come out of this was a decent mathematical education, and wisdom about human nature and society, both of which would come in handy later.

I then made it through ten years of economical depression in 1990's Romania, then made it to Stanford heaven. Like the dog that finally caught the car, I didn't know what to do with it. I rejoiced the atmosphere of intellectual honesty, experimentation, and the contact with my colleagues and teachers, especially Jon Claerbout. I did not realize how important the latter was until years after. Jon pioneered several crucial concepts, among which "hard" reproducibility (i.e. providing _everything_ that is needed to actually reproduce a scientific result, and testing it). I remember him in the early 2000s experimenting with online teaching methods that only started reaching mainstream 15 years later. I also remember him saying "If it's not hard, then you're not learning". I then moved on to experience for five years life in Trondheim, Norway, eight hours drive from the Arctic circle, which was also amazing in its own way.

In 2010 I had the pleasure of enjoying the hospitality of the Geophysics Department at Colorado School of Mines. Then just like insects turn from larva into adult in their lifecycle, it was time to go through five years in the service industry in Houston. Towards the end of this period I even learned to sit still in one place and work for the whole day like an adult, and to not interrupt people when they're speaking. Since 2016 I have been working in a totally different environment, applying my programming skills to other fun things such as the ionosphere and the magnetosphere.

When did you first hear about Madagascar?

Back when I was still at Stanford, and Sergey was a postdoc at Berkeley. Rumor came through the grapevine that he was working on it. I knew that if Sergey had his hands in it, it was going to be good, so I jumped in.

What was the most difficult part in learning Madagascar?

Hands down, getting used to SCons. Yes I understand its advantages, but I think it is trying to do too much for the user, and in doing so hides the nuts and bolts, and becomes slow. That stew was never to my taste, so I was not motivated in learning it.

From your contributions to Madagascar, which one is your favorite?

Anything having to do with multiplatform installation, and ensuring that things conform to the Filesystem Hierarchy Standard. Design and API standards are one of the most important ways to save duplicating work, and being able to take that one step farther.

What advice would you give to those who wish to learn Madagascar or to contribute to it?

The most important would be to understand that, like most open source software, it has been developed so as to fulfill the needs of most of its contributors, in this case university researchers who need to implement, test and share their theoretical work. As it is said in the open-source world, they are "scratching their own itch". Any attention they are able to give to feature requests from users is pure charity.

This is not selfish in any way -- on the contrary, they are sharing everything without being obligated! However if someone's needs as an user differ from those of the developers (for example in the case of an industry user who needs algorithm x, or compatibility with proprietary file format y, or GUI feature z), the best and fastest way to get that into Madagascar is to convince their management to allocate resources of any kind to contributing to the package. The direction of the project is determined by who contributes to it. Open source is a meritocracy, not a parasitocracy.

A great illustration of this dynamic happened when Red Hat discontinued CentOS. The company was effectively giving away its flagship product free of charge, hoping that users would see its value and decide to purchase support. The users in question included many very large corporations and organizations flush with cash, running CentOS on huge numbers of nodes, who never purchased a Red Hat subscription in decades. Much hand wringing and protest was observed when Red Hat took this overdue logical step. Similarly many people bemoan the closing of that picturesque neighborhood restaurant that they never visited.

So, if you want a feature implemented, or wish to keep Madagascar running indefinitely into the future, roll your sleeves, get a witch to convince your management to allocate resources, or give them some argument from Why Madagascar.

Madagascar has a logo, but I never heard of a motto. How about: "If not now, then when? If not you, then who?"

For students: One of the best ways to learn is to contribute. Interested in a certain algorithm? Why not write a little paper illustrating how it works?

If you do contribute -- libraries are such a great invention. Try to keep I/O and parallelization calls in the driver, and separate scientific algorithms in functions/subroutines that can be called by other drivers as well. That makes all sorts of magic possible, in ways you would not have thought of.

Also, if you do contribute, make sure you are not encumbered by the legalese of whatever forms you may have signed with your current employer, which may make anything you create their property, regardless of whether it is related to your work or not. Projects have died poisoned that way.

To the extent that you have a choice, try to find employers which will let you use Madagascar in your work, even if they don't permit direct contributions to the shared infrastructure. Otherwise you will have no itch to scratch, and the flower of your passion will die. That is how my contributions stopped.

I love code, because code does not lie. Code is pure logos, and does not have the faults of humans. If your stuff doesn't work, you can't threaten the program to output something else. Code does not care about your ego. Yes, your reasoning has errors, regardless of who you are. At the end of the day, in order to get that algorithm and that program to work with field data, you have to be honest with yourself. This takes courage and humility. Done enough, and with full sincerity, intellectual honesty may become a habit, carrying into other aspects of your life. Contributing to an open source project may thus provide to those who have the strength to crush their own ego an enrichment which they may realize only decades later.

Regardless of how much or how little you managed to contribute, the important thing is that you honestly did your best to improve the world, even if in some very small way. This offering you made to the world will provide a light that will shine on your heart, and you will feel it.