Just as "No man is an island", no software developer works in isolation from operating systems, programming languages, databases, frameworks, and libraries. Almost as a rule, the best of these third-party solutions are open-source software. This is an apparent paradox, since the open-source world, based mostly on volunteer, unpaid effort, has the characteristic of being chaotic, disorganized, and crazy. Keeping on top of new developments in open source is a big job, and should be seen as a legitimate one.

Choose wisely

Martin Fowler, who has done a great job documenting software vocabulary, explains architecture as "things that people perceive as hard to change." Nearly every software project involves dependencies that quickly reach architecture status. Replacing a project's language or application framework with a better one usually means starting over again from scratch, and this can even be true of databases and libraries. Even a small software project will typically have dozens of dependencies, making it quite hard to pick durable winners.

Architectural decisions are extremely important to get right, all the more so because of the incredible leverage contributed by open-source projects. For most programmers it is hard to admit that our own contributions to our software projects are just droplets on top of an ocean of value was created by others. The effect of leverage is enormous. Forego leverage and competitors who exploit it will crush you, no matter how hard you work.

Time for research

If you're a typical programmer, you probably feel most productive when you're writing and shipping code. What would you think if I told you that you should spend a third of your time researching open source? Does that sound crazy? Horribly unproductive?

Think back to how much time you spent learning the platforms and libraries that you now use to create software. Add to that the time that you spent evaluating alternatives to the solutions you picked (or should have spent evaluating alternatives, in order to responsibly steer the massive learning investment that would follow.) Then imagine the millions of programmer-hours that are invested each year in open source, the new leverage available from these contributions, and the resulting depreciation of your own capabilities relative to the state of the art.

Because software has near-zero marginal cost, the pace of innovation is insane and unrelenting. The world of open source never sleeps. However, obsolescence is observable only in fits and starts. You may ride a winning platform for years without noticing a drop in your pay rate or opportunities, then suddenly wake up to realize that the world has moved on without you. As a profession, software development has few barriers to entry. You don't need a degree, you don't need to purchase expensive equipment, you don't need to pay for instruction, and with open source, you don't need to pay license fees. You just need to sit down and learn how to use all this free stuff. But this same lack of barriers means that you can never relax. You're running on a hamster wheel and you can never stop. My term for programmers who take a prolonged break from active learning is going EOL (End of Life), as in "it looks like he's going EOL with Java."

You might imagine that you can invest a minimal amount of time in scanning for obsolescence and keeping track of new developments, then rapidly adopt new technology when needed. "Let the early adopters bleed," you say to yourself, "I'll jump over when a clear winner emerges." This approach works well enough for incremental change, although doing a decent job of it takes more than a minimal amount of time. The trouble occurs when you fail to recognize a major power shift until the cost of making the switch is very large–perhaps too large for someone with bills to pay, in which case the result is going EOL. This is a personal version of the peril encountered by companies that Clayton Christensen describes in The Innovator's Dilemma, a book that I consider a must-read for understanding and managing your own technology career. The ultimate problem is that we are unable to detect big shifts until some time after they actually happen. Please read Nassim Taleb's The Black Swan if you need convincing about the impossibility of reliably predicting impactful events. The only reliable solution is to make the sure, steady investment in researching new technology that is characteristic of an early adopter.

Conclusion

The comparative advantage of leverage from open-source technology in software development is decisive, but transient. It is my impression that the average half-life of open-source technology is about four years, but that's just a guess. It would be fascinating thing to try to measure quantitatively, although an such attempt is likely to be futile. In the absence of really knowing how long we can expect our learning investments to last, a wise approach is to keep up a steady, ongoing investment over time. Never stop researching open source. Commit a third of your work time to it. The alternative may be a prematurely shortened career.