Fabian Schonholz’s Blog

Since I started this current incantation of my Blog my wife has been, on and off, helping me with edits. English being my second language, my grammar can be weak at time … OK … most of the time. Elizabeth reads my posts and corrects them before I post them … but not the last few. She has not wanted to do it.I asked her and her answer: ”Dude … it is boring to me”

She liked the posts that have a personal human interests, like my moving to the US or about my kids or her … of course, she loves it when I write about her. I agree that some of my business and technology posts can be boring for somebody that does not carry an interest in the subjects. As I went through the list of topics I have been collecting she suggested that I wrote about change but from an emotional point of view, not corporate.

So here it goes. This post is for her….

———————————————-

Life is change and to live is to be exposed to constant change. So you might as well embrace it and enjoy it ….. if it was that easy!!

Throughout our lives we go through so much. We start when we are born. We exchange the comfort of our mother’s womb for the coldness of the world. And we cry. And if we did not cry, we are made to cry. It is the indication that we are alive. What does that say about us?

And the emotional rollercoaster starts.

We grow up and grow old in a world that seems to constantly conspire against us. From the beginning gravity is there … really to help us … but I remember how my kids struggled when they were infants in trying to move and lift their beautiful heads. Gravity was there to help them develop their muscles. I could see in their faces the struggle. Their bodies developed and changed and with that, new experiences awaited.

Crawling, walking, running. Bumping, falling, bumping again, crying. The feelings of not being able to accomplish a task to the level of perfection we want. Slowly developing dexterity but wishing it developed faster, because we cannot, quite so, play with that toy. And the world feels like it is small. And the world feels like a giant.

And we start to interact with other kids. This kid to my right is prettier, the one to the left uglier, in front of me too intelligent or not intelligent enough. We stretch our wings and we bump, we fall, we bump again. We compare and measure against our peers. Feelings rush to us. Feelings which we do not understand. Good feelings all of them. There is nothing negative; these feeling are eliciting us to adapt; to cope, to grow up one emotion at a time. But because we do not understand them we turn them into what they may not be. And more changes.

There is no stopping these changes. We cannot even slow them down. When we experience a good time we want to reproduce it. But since the circumstance are different every time, it cannot be reproduced. We are bummed or disappointed because it just is not again as we experienced it before.

Our bodies keep on developing. Our brains keep on absorbing and new experiences keep on morphing us. More emotional stuff comes with all of these. The baggage is from our parents, from us, from our friends, even from our grandparents. We already experienced rejection, but now it is more dramatic. That girl did not want to go out with me, or that boy said I was such and such. We are marked by these experiences. They prepare us for the future. Of course at the time we do not see it like that.

And life continues.

We go to school, learn all sorts of new things. We go to university and we unlearn every thing we learned before. More changes.

We find our other half, or so we think. We commit to life, or so we think. We now need to adapt to not just being one, but two, despite the promise of independence. Our emotions run us. Our responsibilities drive us. And all along not only do we change, but the world around us changes as well. We grow old; gray hair, wrinkles, reading glasses, kids!! Kids are the biggest change. Of all of the life changing events on our lives, kids just make us rewrite our books. Our plays change. We are super happy and that is when we realize … “now I am responsible for 3 … 4 … 5 …” and the focus changes.

And all along we make a futile attempt to stop all these. Actually, no .. we do not even try … but we want to … no wait, we do not want to. What the heck … how did I get here?!!

Life is changes, whether we like it or not. It is so hard to embrace that fact. Even when most of the changes are good.

And one day, when all is said and done, we are dead.

And the emotional rollercoaster stops.

OpenSource and the Free Software Foundation have been around for a long time and starting in the early 90’s more options have become available. Linux became a somewhat common word and the use of free software became, step by step, widespread not only for home use, but in universities and corporations. This post is not about the history of OpenSource but the concepts I subscribe in my decision to use OpenSource projects.

There is no free lunch.

Indeed there is not. If you think that using free to download software, including operating system or applications then I have a bridge in Brooklyn that I want to sell to you. But the cost is indeed less. There is no cost for the software itself. In most cases you pay for the distribution, which is the media, the packaging and the shipping. But if you do not even want to pay for that you can always downloaded it from the Internet. The cost there is bandwidth.

So, what other more important cost is there? People. And the cost of these people is higher than FTEs focusing on Windows – We can talk about Sun Solaris, or AIX, or HPUX, which are not free and are also versions of Unix, which enter in the people cost discussing, but since those tools are not OpenSource we will ignore them. A good and/or decent Unix sysadmin with deep knowledge of Linux or FreeBSD runs, depending on experience, at no less than $65K/y. And that would be for an entry level guy. A similar sysadmin for Windows will cost $45K/y. So yes … it is more expensive, but for every 10 Windows servers you need 1 FTE to administer them. For Unix based system, you need 2 every 40 or 50. The math works out that to fully support a cluster of 50 Windows servers you need to spend $225K/y in people, not including license fees. For the same Unix cluster $130K/y. And there are no license fees.

Transparency.

To me transparency is a primary element of security. And transparency is in regards to being able to audit the code. As a CTO one of my roles is to be mindful of the company’s assets, both, digital and physical. So, having access to the code to verify its security is important. Do I look at the code each time I install a server? No, but once upon the time I did. And I try to follow up on security patches. And even if I do not, one of my two guys – not 5 – will.

But that would be at the OS level. At the application level works the same way. Any OpenSource application that you install, it’s code is available for you to scrutinize. Moreover, you are encouraged to do so and to report any finds … specially in a public way. Transparency in this case is about the lack of secrecy. It is secure because it is build secure and security exploits are widely communicated for the community’s benefit. It is also good to provide a security patch with the communication, but not obligatory. You are encouraged to contribute.

Reusability.

I am big in reusability. Reusability to me means several things but most importantly from a business point of view – not to be confused with pure technical meanings of reusability – is expediency. If I can start a project from 50% done by basing it on an OpenSource project then why not? I have the code and I can modify it. It means getting to market faster. It means less development cost. It means starting from a more-less stable code base and if done right, retaining that stability.

On one of my previous posts I discussed buy vs. build and the gist was that if it is core then you build. How is starting from 50% relate to that? By the nature of OpenSource you OWN the modifications, but you need to disclose that the base is OpenSource.

But reusability does not need to be on entire projects. Maybe parts of a given project are the necessary components you are looking for. Reusability is core to OpenSource, in all sorts of ways.

Quality.

Quality is a hard concept in OpenSource and can be argue in both ways, against and in favor.

Against: A software producing company has a dedicated QA team to assuring the quality of the product. They know the product in and out.

In Favor: Thousands of users are proxies for QA teams. And thousands of users can find more issues than a few dedicated QA guys.

It is not about the quality of the dedicated team. I have worked with dedicated QA teams throughout my career and some of the folks on those teams were the best; but you cannot argue with share numbers and probability. The more people looking at the code or using it, the better the chances to find obscure issues.

Moreover, many of the found bugs are reported with the solution in it – even the code that fixes the bug – which accelerates the rollout of the fix. Quality in OpenSource is pride the community takes very seriously.

Community.

Community is an important aspect of OpenSource. Without the community there would not be OpenSource. Without the community there would not be quality on OpenSource projects. The community helps with problems by providing the solutions to the specific problem or similar problems.

I used to be a Red Hat beta tester for JVMs. Since I was a Java developer and used Red Hat, I always installed the Blackdown JDK and tested it as part of my regular development duties. I encountered problems and posted them and if somebody had a solution they would share it with me. I did the same. Once every other day, as I posted issues, I would scan the posts and provided answers if I had them. To a less extent I did the same with FreeBSD – which I also used.

On closed source software, it takes a longer wait to get an answer, even in the cases where you paid for ongoing support.

Robustness

And this is where things get a little dicey. Is OpenSource more stable than close source? Part of the answer does reside with similar arguments as in the QA portion above, and part of it with the community argument as well. I would agree that early days of OpenSource maybe a small percentage of the projects had a high factor of robustness, but that is in the past.

Machines running Linux or FreeBSD, at least in my experience, have stayed up error free, even in the face of configuration changes, longer than machines running Windows, or Solaris, HPUX, etc. Part of the robustness comes from being able to use commodity-computing devices. There is something to say about using the lowest common denominator in terms of hardware.

Another element that brings robustness is, as stated above, transparency. Thousand of people looking at the code and contributing does make a dent – in the positive sense – towards stability and robustness. But robustness also comes from choices; as a CTO I have to choose what is best for my company and in some cases it does imply using bleeding edge components.

Robustness is a choice, and OpenSource allows you that choice.

There are other arguments, including philosophical ones with which I totally agree, but these are the most important to me as a CTO:

• Cost
• Ownership
• Quality
• Help
• Robustness

As a technology executive I am always faced with the decision to build vs. buy. For each feature and for each project, for each component that is implemented, the decision has to be made. And it is seldom easy. There are many factors that play into making a decision and it is not always clear what the long-term effects are. One of the bigger factors is time-to-market, and not less important is integrability. So, how do I make the build vs. buy calls?

Company type is important. Different companies have different needs. And those needs should be fulfilled in different ways. A technology company is different from a service company or financial institution or factory. But because they are different does not mean the way they look at technology differently from each other. The question of technology usage has to do with the purpose of it.

It seems obvious that a technology company will tend to build most of what it uses. But that may not be the case. Similarly, a service company, we would think, would buy and integrate what they use to conduct business every day. And again, that may not be the case. It is all in what is core to the company and what can be best leveraged on a financial event – M&A or IPO.

The way I look at it is that if technology is core to the value of the company and intrinsic to the company itself, then you build it. It is an investment that will pay big dividends. And all ancillary technology should be bought. For a non-financial company it makes no sense to build a general ledger. There are some good accessible products that will do just fine. For a financial company may be worth reinventing the proverbial wheel if they have some new paradigm they want to implement, but if they do not, then most likely it would be fine with a tool like Oracle Financials – I will let the CIO/CTO for such a company decide.

But a company’s technology does not need to be build from the very beginning. Proof of concepts can be constructed on top of canned software. There are a myriad of sites that implement different business all built on top of Drupal, a content management system. The only concept these sites have in common is the fact that they are content rich and that content needs to be managed. But how the content is displayed or monetized, that is different. Drupal is a great tool that can get you going fast, meet your market on a short amount of time, with as little as possible development investment. And then what? Then, again, if owning 100% of the core of your technology is important from a valuation point of view, you start re-implementing and replacing little by little the bought components.

At the end you build if your technology adds to the valuation. Else, you buy. Nobody wants to buy or invest in a company that does not own its most precious asset, technology. Nobody wants to buy or invest in a company that is at the mercy of some third party technology producer.

For large established companies I propose a very similar argument, but with a more macroscopic approach. Larger established companies should be on the lookout for small or large companies that complement them and help expand and cement their position on the market. These acquired products may remain on the periphery or become core.

But, what about their internal technology folks? These established companies have core products that they own, that got them to where they are. These folks work on that and keep on building new version of the core products. Also, they build more core products that the company would own and would positively affect the value of the company as a whole. The companies that they buy in combination with the core products create a more powerful market offering.

In the end, it turns to be a balancing act between core values to the company, existence of quality products, time to market, budget and what strategy the company follows.

As I look at my job and what I do, I am continuously confronted with the task of developing and completing projects to meet the ever-growing company’s market. We continue to expand our needs and as the company grows and we meet our market opportunities, so do the risks and execution complexities. Expediency becomes central to execution. In other words: how do we do more with less and faster?

In my opinion there are three ways to approach technology development and company growth, whether for a start-up or an established company. These approaches are about the business of technology and not the technology of the business. They are about technology as a business tool and technology as a business process.

Just like everything, each one of them has pros and cons:

1 – Purist. The purist approach is based on having all the answers before hand. No opportunity is pursued unless all is known about that opportunity and an existing product is 100% ready to answer the opportunity.

Development cycles are long and tedious and innovation is not the order of the day or the charter of the technology group. On the other hand, all processes are highly repeatable and steady. Also, priorities are SET IN STONE.

I do not think this model works at all. It is too rigid and stifling. For a start-up it spells dead and for progressive companies, it means “getting stuck in the mud”. It is important to note, however, that there are companies that follow this approach very closely and are VERY successful. These are companies not only with deep pockets, but with really long term visions and strategies and are largely unaffected by market changes. Also, their competition behaves in similar ways and innovation is “acquired”.

2 – Opportunity. The opportunistic approach is based on letting the company flow as opportunities develop. Business development seeks out opportunities on areas that are related to the company’s market, but they may or may not be close to it. As opportunities present themselves new products are developed to fulfill the opportunity. And if the company has an interesting idea that solves a good problem, these opportunities come faster than they can be handled. And if the company is a dud, then being driven by opportunities that do not exist generates a quick exit, however, not a successful one.

Development cycles are all over the place. Priorities change on a regular basis and many projects get started and never fully finished. And there are more products/projects to do that can be done. Thus, the continuous change in priorities and lack of 100% completion on projects.

For start-ups this is not such a bad approach. It is very eroding and risky, but ultimately success comes from being able to reign in the opportunities, priorities and products together at more less the right time. The problem is that this creates many one-offs that are hard to integrated with each other and sometimes the quality of the code is not the best – no matter how good the developers are – and documentation is lacking.

For established companies, this is probably one of the worse methods to follow. As a company goes from start-up to the growth face, the issues of priorities must be resolved and productivity needs to be managed and understood. Product road maps must be respected and business development needs to focus. This focus is not about not looking for opportunities outside of the core, but it is about looking for opportunities that do not represent too much of a change to the products and priorities and that are inline with the growth strategy the company is following.

3 – Growth. The growth approach is based on looking at a company in a continuous strategic manner. Products and projects are selected based on a crafted road-map and business development targets opportunities very close to the company’s core products and/or services. Additionally, all development is done in a fashion where high reusability is ALLWAYS achieved.

The key for growth is reusability. In other words: leverage what you have so to reduce cost of new product development reusing existing frameworks. New product development does not just mean cost of technology development, but full product development cycles, which include technology. Also, reusing does not mean lack of innovation, if anything it all about innovation, but on the shoulders of existing products and services.

Another key to growth is full understanding of the market the company plays in and other markets into which the company can expand. But these markets should have similarities as to be able to reuse not only technology, but also the business models, and by extending the company’s business model as well. This understanding produces successful and flexible strategies that propel companies forward.

So … what is the right model to develop and keep a company growing? My inclination is to choose a combination of Opportunity and Growth, although, I would still err on the Growth side. But that is for startups. It is hard to ignore opportunities, especially early stage when the company is still looking for an identity and trying out the idea that created the company against the market. Flexibility for an early stage company is paramount. But sometimes flexibility gets us in trouble and produces lack of focus. In the end, lack of focus is the biggest killer of any startup.

For companies that are past early stage, Growth is the best way, again in my opinion. The growth stage is where companies make it long term. Growth is about understanding the market forces and incorporating them into the strategy. And that strategy turn into a long-term plan that include “what-ifs” scenarios. It is also during this stage where technology is re-factored, possibly rewritten and new products are built to update existing ones using the same and expanded API set.

For companies that are well established I think that a middle ground between Purist and Growth should be the model. Innovation MUST be a focus of an established company. It is the only way to keep an edge and to stay competitive, but existing products need to be maintained and updated. So, long existing products should have a steady release schedule and roadmap, while other areas should, again, focus on innovation and leapfrogging the competition.

One more point I would like to make: The stage of growth and development of each company should dictate what is the most optimal method or approach is best for each company. Each company has different cultures and obstacles to overcome to keep on growing, so, to think that one method will apply to ALL companies is silly. Best practices or writings like this, whether you agree or not, are just guidelines and at the end, each company has to find its own way.