How Software is Built

Interviewers: Scott Swigart, Richard Bowler, and Sean Campbell

Interviewee: Marc Miller

In this interview, we spoke with Marc Miller about his views on the current state of open source software.  Marc works for Advanced Micro Devices (AMD), and in January, Marc took on a role as the open source software evangelist in the AMD Developer Outreach organization enabling Linux kernel and application developers to develop optimized code using both AMD and 3rd party tools and resources. In his role as a software Alliance Manager for AMD 2001-2006, Mr. Miller played a significant role in developing a Linux marketing strategy with a focus on integration of AMD technology with software tools developed by the open source community and industry partners. Throughout his career at AMD, Marc has been a key contact for open source developers wishing to work with AMD, and has been an open source ambassador for AMD, helping to coordinate outbound and inbound communication between AMD and Linux developers.

In this interview Marc talks about:

• Challenges that open source companies have when competing with proprietary software
• Advantages of open source
• Choice also has disadvantages
• Is open-source anti-capitalism?
• The PR value of being open-source
• Open-source is less idealistic and more pragmatic today
• The future is blending open-source and proprietary software

Continue reading…

An interesting study can be found here.

Both Scott and I will be at OSCON 2007 in Portland and we would be more than happy to meet up with folks. We’ll doing a variety of Q/A focused meetings as well as some video interviews while we are there and we’re happy to schedule more with folks who are interested.

If you’re interested in participating or just connecting up over a cup of coffee email me at seancampbell@technologyevangelism.com

Interviewers: Scott Swigart, Sean Campbell, and Richard Bowler
Interviewee: Phil Costa

Phil Costa

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Phil Costa who is the Director of Product Management for Flex and ColdFusion at Adobe, with responsibility for product definition and strategy of the Flex product line. Prior to joining the Flex team, he was product manager at both Macromedia and Allaire and led XML and Internet middleware research at Giga Information Group. Phil has a Master’s degree in English from Boston University and an undergraduate degree from Swarthmore College.

In this interview, Phil talks about Adobe’s decision to open-source the Flex SDK. In specific, Phil talked about:

• Background on the Adobe Flex SDK
• Why open-source the Flex SDK
• Risks in open-sourcing the Flex SDK
• Why the MPL license was chosen
• Advantages in open-sourcing the Flex SDK
• The risks of people forking the build

Continue reading…

Interviewers: Scott Swigart, Sean Campbell, and Richard Bowler
Interviewee: Michael Howard

Michael Howard

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Michael Howard, a senior security program manager in the Security Engineering team at Microsoft, and an architect of the security-related process improvements at the company. He is the co-author of many security books including the award-winning Writing Secure Code, 19 Deadly Sins of Software Security, The Security Development Lifecycle and Writing Secure Code for Windows Vista.

In this interview, Michael exposes how Microsoft developed the Security Development Lifecycle, which has decreased the number and severity of vulnerabilities in their products. Michael also directly challenges the notion of “many eyeballs” leading to secure code. Highlights include:

• With proprietary software, you can mandate the process.
• Security Development Lifecycle (SDL) was needed because of the pandemic of security vulnerabilities.
• Goals of the SDL.
• Quantifiable results of the SDL
• There’s denial about the vulnerabilities in non-Microsoft products.
• As Microsoft products are hardened, hackers are going after softer targets.
• If you think “many eyeballs” equates to secure code, you’re out of touch with reality.
• Training is key for building secure products.
• The SDL can’t just ban things, it has to provide better alternatives.
• The Microsoft’s central security team has stopped products from shipping because they weren’t secure enough.
• The Bill Gates memo that started it all.
• The next security frontier: social engineering.

Continue reading…

A while back, I wrote a blog post about process. In that post I pointed out that closed source companies have the “advantage” of being able to control their development through the application of robust processes surrounding the SDLC. This gives them the ability to carefully manage costs (especially personnel costs) and the quality of a release. In the same post, I wondered how open source projects apply process, since the motivation of a paycheck is missing, and the distributed nature of most open source teams makes process enforcement virtually impossible.

As we’ve continued our investigation, and interviewed several open source people, it has become clear that open source projects have rejected traditional process, and replaced it with a new paradigm: the mailing list. So what is it and how does it work?

Continue reading…

Interviewers: Scott Swigart, Richard Bowler, and Sean Campbell
Interviewee: Stormy Peters

Stormy Peters

In this interview, Scott Swigart, Sean Campbell, and Richard Bowler interview Stormy Peters of Open Logic.  Stormy is a frequent keynote speaker on business aspects of open source software at major conferences such as the Open Source Business Conference and the O’Reilly conferences. She has addressed the United Nations, European Union and various U.S. state governments on open source software. Stormy is a co-founder of the non-profit GNOME Foundation, which is based on open source principles to encourage the development of a computing platform, comprised of free software, for use by the general public.

Stormy has impressive experience in the field, and this interview covers a wide range of topics, including:

• When does it makes sense to open-source a given project
• Considerations for open-sourcing a product
• How open source software is supported
• How open source is and isn’t good at fixing bugs
• Choosing between using open or closed source
• How open source software is actually built
• Why open source projects don’t really fragment (fork)
  that much
• The pain of incompatible packages
• And, what OpenLogic does to take pain points away

Continue reading…

Here are some key take-aways from the Mark Gross interview:

• Open source projects are sometimes required to carry closed source proprietary code, usually in the form of drivers. This is unpopular, and the open-source community pushes pretty hard for open-source drivers.
• By definition, all kernel code is written by “the community”. It’s also mostly written by corporations. This is not a contradiction.
• Corporate development is critical to the success of open source.
• All code is submitted to the mailing list for approval. Comments are initially about cosmetic issues. Then, they become more substantive.
• Commenting on code is a way to build a reputation. Reputation is important in becoming a maintainer, getting your code added the kernel, and being taken seriously among the community.
• Sometime, there are turf/political battles over sub-systems. Maintainers have broad discretion for what code is approved.
• The mechanisms for secure code are 1) many eyeballs, and 2) quick reaction to vulnerabilities.
• A contributor generally provides bug fixes for the latest version. Back-porting is often not the responsibility of the code author.
• Getting code included in the kernel is a technical process and a political process.
• Some people volunteer to work on the code as a career path, hoping to get hired or sponsored.

This week, we posted two solid interviews. The first is with Shawn Burke, a Director in Microsoft’s .NET Developer Platform group. The second is with Mark Gross, an engineer in the Open Source Technology center at Intel Corporation. Shawn really helped to open our eyes to the process that Microsoft uses for building software. You can read distilled highlights from the interview here, but I strongly encourage you to read the entire interview. Mark Gross was equally illuminating regarding Linux kernel development. Again, it was great to peel back the covers and get insight into how the kernel is put together. A distillation is coming, but the full transcript is a good read.

We have many more interviews in the can, and we’ll be posting them up on a regular basis going forward. I’d like to thank everyone in the open and closed source communities for being willing to talk to us. The conversations are helping us greatly as we perform our investigation.

Here are some key take-aways from the Shawn Burke interview:

• Microsoft product features come from the bottom-up, and top-down.  Product teams come up with feature ideas, and product execs define broad pillars for the next version.  Features must align to pillars.
• Microsoft doesn’t open source some things like Windows because they’re concerned that code would get included that isn’t licensed properly to be included.
• Community Tech Previews are early builds of a products, released for download.  These are designed to get community involvement and feedback early enough in the product cycle to affect the final product.
• Bugs submitted to Connect go into the same bug database as bugs submitted by internal testers and developers.
• Microsoft thinks hard about what to make extensible because there’s a cost to building extensibility points, and an even larger cost in supporting them.  It’s necessary, but product teams are conservative about it.
• Security is the top priority.  Each feature goes through threat modeling, security review at the code level, static code analysis for security, review by a separate security team, etc.
• Test matrices are massive, and include combinations of supported operating systems, other products, testing around clean install, upgrade, reinstall, etc.
• Performance optimization often happens around key scenarios (cold machine start to first form displayed, for example)

Interviewers: Scott Swigart and Richard Bowler

Interviewee: Shawn Burke

Shawn Burke

In this interview, Scott Swigart, interviewed Shawn Burke of Microsoft. Shawn Burke regarding the way software is developed within Microsoft. Shawn is a Director in Microsoft’s .NET Developer Platform group. Currently, Shawn is focused on building shared-source projects focused on new developer technologies from Developer Division. Since he started working at Microsoft in 1997, he’s worked on Visual J++, Windows Forms, and Visual Studio.

This interview covered a wide range of topics some of which follow:

• Eating your own Dogfood at Microsoft
• Product Idea Triage at Microsoft
• The difference between Product Milestones, CTP’s, and RC’s at Microsoft
• Closed Source Cores with Open Source Add-On’s
• Extensibility and Software Development
• Security, Reliability, Scalability and other “ities”…

Continue reading…

Interviewers: Scott Swigart and Richard Bowler

Interviewee: Mark Gross

In this interview, Richard Bowler and Scott Swigart interviewed Mark Gross of Intel. Mark Gross is an Engineer in the Open Source Technology center at Intel Corporation. He primarily works on telecommunication computing platform Linux OS support for Intel, along with some additional activities. Mark is also the chair of the power management working group for the Consumer Electronics Linux forum. Mark is a robotics hobbyist and participates in PARTS http://portlandrobotics.org and the occasional Dorkbot get together.

This interview covered a variety of topics some of which follow:

• The role of the Open Source Technology Center at Intel
• Device Drivers and OpenSource distros
• Who determines what gets into the Kernel
• Turf battles with Hibernate
• Security and OpenSource
• Critical Mass and Buy Off in the Open Source community
• Peer Review of Submissions

Continue reading…

I had two interesting conversations today. One with Patrick Moran of NASA’s World Wind project, and one with Ryan Waite who works on Microsoft’s High Performance Computing platform. I’ll be posting the full transcripts in the future, but here are some random observations.

Continue reading…

There was a good post over at Open at Adobe (subscribed) about what it’s like for an ISV to “support Linux”. Linux is established. It’s in every fortune 500, and it’s certainly something that ISVs have to look at supporting, especially for server based products. But Dave indicates that it’s not trivial to actually do that. I’m curious, what are the specific issues that ISV and IHVs run into when they tackle supporting the various distros?

The Linux Hourglass

I’d like this research project to output some diagrams of how various open and closed source software is built. I spent a couple hours looking into the process for how code makes it into the Linux kernel, and came up with the following diagram. Before the diagram, let me caveot the heck out of this by saying 1) this diagram has probably allready been produced, much better, and I just wasn’t smart enough to find it, and 2) my diagram is wrong in a number of important ways, I just don’t know exactly what those errors are.

Here’s the 1st draft. Please respond with corrections either as comments to this post, or you can email me directly at scottswigart@gmail.com.

Inspired by some of the conversations we’ve been having, I’ve been thinking about how a program changes over time. If you look at spreadsheet programs as an example, they started out pretty simple. They were single-sheeted, with a limited number of cells, and a set of (mostly financial) operations you could perform on cells. Now they are multi-sheeted, explicitly extensible, graphics rich, and so on. What drove the addition of these specific features in later versions? What drove the order in which those features were added?

I have a pretty good handle on how those decisions are made in a closed source environment. Version 1 is usually a bare-bones implementation of the core vision for the product. For subsequent version, a product manager talks to customers and developers about what is needed beyond the base functionality. (Some have complex processes for doing customer and market surveys, while others use a less formal approach.) At some point, the product manager will release a Product Requirements Document, outlining desired changes and additions for the next version release. There is then a negotiation with the technical management staff to factor in cost, budget, and resources. Usually, some subset of the requested functionality is authorized for implementation.

Continue reading…

In our world of malicious hackers, software security is a primary concern. Any program that has active software interfaces, whether to the file system, a network connection, the Internet, or some other piece of software, is potentially vulnerable to attack. And unfortunately, some devote significant resources to engaging in those attacks. Since those attacks can lead to things like denial of service, program crashes, and destruction or theft of critical data, enterprise software consumers must make every effort to minimize their exposure.

The first step in minimizing exposure to hack-attack is to use software that is secure in the first place. While this is obvious, it’s also probably impossible. Any complex system of software will include bugs; it’s the nature of the beast. And some of those bugs are likely to take the form of security vulnerabilities. So where does that leave us?

Historically, the approach by software teams, whether using open or closed source development methodologies, had been primarily reactive. A very simplified, general view of software development, both pre and post release, looks something like this:

• Implement the software.
• Test the software for bugs, including security vulnerabilities.
• Fix the important bugs found.
• Release the software.
• As security vulnerabilities are discovered in the field, fix them in the code and release patches that repair the installed base.

Continue reading…

Microsoft just announced that they’re cutting several key features from their upcoming virtualization technology codenamed “Viridian”. To me this is a case study in some of the differences that you find between closed and open source development. Basically, it comes down to how each methodology grapples with the very first thing you learn about project management.

People at one time hoped that Viridian would ship at the same time as Longhorn Server (LHS), but Microsoft announced that instead, it would end up shipping 6 months after LHS. Apparently, Microsoft has made the decision that Viridian will not be allowed to slip further. In other words, the product has switched from being feature driven to being date driven. On that triangle, “fast” (a.k.a. schedule) just got nailed down.
Continue reading…

In our recent interviews with James Whittaker and Michael Howard, the importance of process came up. These two guys are focused on limiting security vulnerabilities in Microsoft software, so the conversation centered on security processes, but it’s just as true in all phases of software development.

It seems clear to me that closed source development has a built in advantage when it comes to process. It’s all in the fact that all phases of contribution are captive. (I know, that’s brutal.) What does that mean? It means you can mandate processes, and you can enforce them.

Continue reading…

CDW has repeated a survey done last November to track Windows Vista adoption. You can download the report for the cost of your e-mail address. Some key findings:

The top percieved benifits are:

• Improved Security (78%)
• Improved Performance (56%)

It’s pretty interesting to me that people think Vista will run faster than their current OS considering the increased hardware requirements for Vista. I also notice that people don’t seem to think that Vista will be great at supporting open standards (or don’t care if it will).

Continue reading…