Recently i read a quite interesting article on TCP Fast Open (TFO) support in current Linux kernel versions. The approach itself isn't really that new, but with a heavyweight like Google backing the renewed effort things seem to get more traction this time around. Although the effort to get TFO recognized as an official IETF draft is still in the experimental state i thought this would be a very nice feature to have in upcoming versions of the IBM AIX operating system. To determine if there are any plans or even a PoC implementation already in progress i opened a PMR with IBM. After some back and forth with first and second level support and AIX development – of which i'll spare you all the gory details – the digest was:

As this is in experimental state, […] this won't yet be implemented. First an official RFC would be necessary.

While i very well understand the necessity of standardization on the protocol level in an internetworked IT world, i was rather disappointed by the brush off response and really would've appreciated a bit more of a “can do” attitude. Is there really no CS student interning or an entry level developer being trained at IBM to whom this task could have been given for a PoC implementation? Not to mention the fact that i was offering my spare time to implement and test a new feature that their product would benefit from.

I think this case is a very good example of several issues:

• open vs. closed source: In a closed source environment the degree of influence you have on the implementation of your individual and possibly rather obscure wish for a certain feature is very limited. Factors like available resources on vendors side, wide-spread use case, possibly large user base, chance for generation of additional revenue, etc. can contribute to the implementation of your feature, but they are to a large degree out of your direct control.

  In an open source environment on the other hand you can just enhance the code with the feature you need – or hire someone to do so, if you're personally lacking the required skill set. The enhancements can flow back to the upstream version if accepted and deemed generally useful by the original developer. But even if they aren't you can keep a local fork or patch set with the enhancements you see fit.

  Generally speaking, with open source the focus shifts from the “if” you can get certain features to the question of “how” and “when”. IMHO the latter results in a much more constructive, fruitful and generally positive discussion with your peers.

• slow giant vs. agil midget: Large companies like IBM, Oracle, Microsoft, SAP have a rather hard time dealing with change, agility and flexibility issues. Granted, compared to smaller, more agile companies they are certainly much harder – but not impossible (see the current HP-debakel) – to sink. But due to the ever increasing internal overhead, the bigger they get, the more time they spend dealing with anything else but their primary line of work, making them harder to steer and more susceptible to a rapidly changing environment. In the current fast paced IT world this usually means, that a considerable amount of real innovation happens at smaller companies. With their hands on mentality, flat hierarchies, quick decision-making, low process overhead and high degree of motivation, they are better prepared for a rapidly changing environment and can utilize this with a shorter time to market for their products. More often than not those agil incubators for innovation get gobbled up by a slow giant (e.g. Sun vs. MySQL, IBM vs. XIV, EMC vs. VMware, etc.) which hopes to rejuvenate or reinvent itself in the process. Unfortunately this process is also usually accompanied by a considerable clash of cultures, followed by a brain-drain and any other kind of general digestion problems. Instead of catching some of that innovative virus, the slow giant diverts energy to complete the assimilation of the new aquisition by imposing every facet of its cumbersome nature onto it, thus becoming even slower and more bloated in the process.

  As an example, I recently talked to an ex-IBMer who had worked in TSM development for about 10 years before going into business for himself. He described his typical work week as 90% meetings and 10% “actual developer work”. The 10% included actual coding and related work as well as work on second and third level support cases. This means that 90% of a developers time and manpower are directed towards keeping a bloated internal environment afloat that probably adds far less to the actual quality or marketability of the product than the remaining 10% of time and manpower. I figure similar numbers apply to any other IT-giant.

• process-oriented vs. customer/community-oriented: Recently i read a rather nice article by The Registers Trevor Pott on the subject, that made some very interesting points on the subject of traditional vs. community based marketing. Although i personally despise EMC with every fiber of my heart, i still admire them for the bold decision to keep VMware a seperately run entity. As described in the article, VMware has a very good culture of community management, which is very sensitive to the atmosphere in the user community and to the needs of their customers. People inside VMware running this, seem to have the authority to initiate development of new and requested features or to bump development in the right direction. IBM on the other hand only tries to mimic such a community by its developerWorks, but a community management authorized to actually initiate changes in products seems to be missing. The IBM culture is in that respect still very much oriented towards its hierarchy of sales, revenue and traditional marketing. If you are a prospective customer and IBM sales has to compete with other vendors, you can get any product feature developed you can possibly dream of, because IBM sales has a strong position against development. If you are on the other hand an existing customer, generating no new revenue, you are only listened to by sales – and thus development – if you immediately take out the big guns (i.e. “… if not, we will be a new customer to IBM”). IMHO this is a increasingly failing concept, because nowadays customers have more and other options when it comes to vendor selection. Those might be more or less painful ones, but they are there nonetheless. A continuous and more immediate connection between customers and development might be a better idea.

Although this post kind of drifted off the original TFO for AIX subject, brushing several other subjects in the process, i hope it was still worth the read. I'm very curious of how IBM and several of its product dinosaurs will hold up against their new, upcoming and faster paced counterparts from smaller vendors and from open source projects.