The corporate hijack of open source code

Big corporations like Monsanto somewhat resemble the Borg from Star Trek: you will be assimilated. Aside from the radical anti-globalist rhetoric of Vandana Shiva, patenting seeds is a very monstrous thing to do. I mean, I don't like the thought of people stealing my ideas to make money that would've otherwise gone my way, but the whole intellectual property deal already is such a slippery slope. To tinker with living organisms is bad enough, but to patent them is crossing the line. I don't want to be drawn into a political discussion: this entry serves a purpose. I'd like to address the corporate undercurrents in open source software.

I'm a proponent of open business. I like to share ideas as they emerge, at least with a small circle. In my last post I wanted to raise awareness for the problem I have with object-oriented programming. After writing it, and watching the interview with Vandana Shiva, I suddenly became aware that the same concept of patented seed doesn't only apply to closed-source software, but also to the whole object-oriented paradigm.

To summarize the find I made: classes are molds placed upon the world from which some species of things or beings take their properties and behavior. In a corporate environment this worldview is very fortunate: things and beings (if you'll allow the distinction) are born with certain a priori characteristics that fit well into the workflow. They have a fixed role in the process that is both efficient and controllable. The term "human resources" springs to mind. Things and beings are thought of as predestined in the course of action, and the less they deviate, the smoother the process will be. Also, think of the chain of inheritance in object-oriented programming: the corporate hierarchy delegates personal responsibility into non-existence. If the world could be modeled according to its role in a corporation, then the corporation would become all-powerful. Chuckle at it all you want, rest assured that this naive thought is in the mind of your CEO: it is the mind that produces classes.

The convergence of technologies Shiva refers to I call "the programmability of natural resources", and by now it's obvious that the object-oriented view made this convergence possible. Classes can be seen as seeds that are branded, and the exploitation of them in code is nothing short of software imperialism! People who use, for instance, Objective-C are forced to work this way. I can remember the day when ActionScript 3.0 for Flash was introduced: all my code needed a complete objective overhaul. And for what? JavaScript never had this rigid requirement... Perhaps because classes can be more easily patented? That would explain why the same thing is happening in the pharmaceutic industry, in bio-tech, in energy production, etc.

Lately lots of open source initiatives have come to the same point: forced objectivity. I won't argue that this approach isn't efficient or doesn't produce higher quality code: it does! I've been using a JavaScript toolkit that is object-oriented from the bottom up, and it's undeniably a very good one. But I'm considering getting off the bandwagon and reviewing my options. It feels kind of liberating and a bit scary too. You could argue: it's just a way of getting the job done. But is it? Perhaps this restraining order is all that prevents us from becoming very powerful and independent programmers. Or perhaps I'm just more paranoid than ever. You decide.

I'd finish this post with drawing relations between object-oriented programming and Darwinism, Kantian philosophy, conspiracy theory, but hey, that would just be pointing out the obvious, right?

Comments

Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

Sometimes a decision must be made. I have invested many hours in a standard that is quite complex and tedious to maintain, and that was great fun, but enough is enough. Why did I invest in XForms when it took so much effort and time? Because I believe standards are good and good standards come from the W3C and the XML community. Also, I always had somewhat of an inferiority complex in IT development that I tried to compensate by using techniques supposedly invented for common folk, i.e. non-programmers. Both are bad reasons from where I now stand. I took up XForms because I was infected by the enthusiasm of a friend (who was even quicker to abandon it) about 3 years ago. At first I assumed it just used a model from which to infer a form. It turned out it was like a superset of HTML forms with options for displaying and validating data. This was largely taken up by HTML5, as we all know. The Model remains the core of XForms, but the W3C is slow to respond to innovations and t...
Read more

JS Journey into outer space - Day 5

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 5 It's time to add more operators. We already have map , but what if the mapping function returns another "container" value, like an array or observable? 🦉 In RxJS some operators like switchMap , concatMap , or mergeMap will expect a "project" function that returns an observable (or promise or array), but what happens then? First map is applied with the project function and after that the result is "flattened". In other words: when the returned (inner) observables emit, the mapped (outer) observable emits those values instead. Since RxJs streams have a specific async behaviour the flattening process takes concurrency into account: mergeMap will flatten inner observables whenever they complete, regardless of the order, but concatMap will preserve the order of the ou...
Read more

JS Journey into outer space - Day 4

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 4 Now we have modified transduce to handle async it's time to figure out how it can handle observables. Kickoff 🏈 First we need to pass the onNext function which kicks off the callback chain. In RxJs this is called subscribe instead, so let's rename the parameter and the callbacks to be more in line with RxJs : function transduce ( input , fn , subscribe , onError , onComplete , init ) { subscribe ( input , { next : ( cur ) => { init = fn ( init , cur ) ; } , error : ( err ) => { onError ( init , err ) ; } , complete : ( ) => { onComplete ( init ) ; } } ) ; return init ; } ; 🦉 Observables are considered a push-style of dealing with many values, while generators are pull-based. In...
Read more