Open Source Software is a critical asset in development because it allows your developers to build on the backs of others, and focus more of their time on building the core business value during tight schedules. The biggest value may not be the infrastructure components, but the frameworks and libraries that can lessen the amount of code your developers have to create. Often companies get started with open source via infrastructure components, such as CentOS, Tomcat, or MySQL, but the greater value of open source, in my mind, is the increase in productivity that comes from utilizing the broad base of frameworks and libraries available to reduce the time to market of feature development. Today's development is more about constructing solutions rather than completely coding those solutions from scratch. Open Source provides the broadest set of components available to build upon.
I was recently reminded of this value in two separate blog posts. One was a post by one of our engineers, Jeff Gran, who summed up several reasons why open source is often very high quality and why open source software is critical to his development. The Open Source community contains a broad set of solutions, many of which are libraries targeted to solve very specific problems. They often follow the mantra "do one thing and do it well." This creates targeted solutions that are vetted by many more people than a development organization often has at its disposal. These well-tested, targeted solutions become building blocks that can be leveraged to provide a pre-fab foundation.
The other reminder comes from a completely different viewpoint and talks about the process of creating software. It's a blog discussing the recent management shake-ups at Apple. While I really have no specific opinions or amazing insight on the management team at Apple, one passage in the article really caught my attention:
Unlike in the Jobs era, when the company would ship features when they were ready for primetime, a culture of schedule-driven releases has become commonplace.
The time-based schedule is one of the reasons why Siri and Maps arrived as half-baked products and were met with derision. Many engineers inside Apple could foresee problems with Maps. Why? Because Maps were driven by a time schedule.
Now most companies and projects that I've been involved with are driven by the need to deliver value to customers and prospects while meeting certain expectations. For businesses to succeed, they must be able to envision the future and deliver to the market at the appropriate time. Businesses also will have many complex pieces to coordinate between sales, marketing, and engineering in order to make that vision successful. Unless you are lucky enough to be a 500-billion-pound gorilla such as Apple, or have a very specific set of clients, chances are you will have situations where features are required, resources are essentially fixed as the bottom line is king, and those pesky deadlines become really important. In development terms, trying to constrain all three of these factors is like trying to construct a building strong enough to not move during an earthquake. The stress build up will cause something to break. In software, that will be quality taking the hit.
Timeboxed agile methodologies, such as Scrum, try to accommodate this by allowing that deadlines are important, and resources are fixed, so the amount of features that can be achieved must be flexible. This allows for the possibility of realizing fewer high quality features delivered on a predictable timeframe. Lean agile methodologies, such as Kanban, try to accommodate by accepting that the features are important and should be released when they are ready, again with fixed resources, while the exact delivery date may vary. Developers are very bad estimators in many (most) situations since creating software is a bit of an art, which is why it's common to talk about "ideal time" and "fudge factors." Unfortunately, even for some of the most bought-in agile stakeholders, both of these approaches can cause headaches when the features and timeline are a business necessity.
So, when the feature deadline monster does appear, and is necessary, you can either get out the Red Bull and shackle the developers to their desks (hoping corners aren't cut by skimping on the test coverage), or you can prepare your teams by giving them access to a huge repository of ready-to-go components that will empower them to be more productive and flexible in getting the job done.