How Software is Built

Closed source software, specifically Microsoft software, offers a confusing myriad of licensing options. Microsoft license options include:

Full Retail Licenses – Transferable license for software.

Upgrade Retail License – Nontransferable license for software which insures the existence of other qualifying products.

OEM License – Non transferable, even to other hardware which you own.

There are also volume licensing programs like Open Licensing, Select Licensing, Enterprise Licensing, and Enterprise Subscription Licensing. These are targeted at different size companies, and you need to read the details to see which is best for your organization.
There are other special licensing programs like MSDN Subscriptions, and Academic Licensing. These licenses let you build software, but when you put your software into production, you have to buy “real” licenses for the software upon which your solution depends.

A good overview can be found here. You can even pay people to help you figure out the best licensing to choose.

In addition, there’s something called Software Assurance, which is essentially a subscription program which grants you free upgrades.
There are also a batch of licensing programs available to Microsoft partners.

If it seems confusing, it is. You can invest substantial time and research into figuring out which licensing program makes the most sense for your company. If you don’t invest the time, you might end up paying extra for the same software. Some of the licensing programs are also a bit of a gamble. You might sign up for Software Assurance because you want “free” access to something like Longhorn Server. However, if the product slips, you might have paid for a subscription which didn’t get anything out of.

With free open source, there’s none of this. You just download the software and go. The only terms you typically need to consider are the redistribution rights.

As Richard discussed in the previous post, free software is very compelling, even essential, for startups, students, and emerging markets. In an effort to get in the game in these markets, Microsoft announced last week that it will sell its Student Innovation Suite for $3.00 under certain conditions. The student innovation suite includes: Windows XP Starter Edition, Microsoft Office Home and Student 2007, Microsoft Math 3.0, Learning Essentials 2.0 for Microsoft Office, and Windows Live Mail desktop. To qualify, the price of the student’s PC must be subsidized over 50% by their government, and PCs must be ordered in bulk.

Comments run the spectrum from “Who cares?” to “Great!” to “Here goes Microsoft trying to kill Linux.”

Here’s a brief roundup:

• Microsoft’s $3 anti-Linux weapon
• Machines would run about $300
• PC World (the comments are more interesting than the article)
• OLPC Board Member says it’s a good thing (and OLPC has 1 million orders)
• Seattle PI
• iTWire says “Here kid, the first one’s free.”

My thoughts on this:

• Microsoft is doing this to compete with Linux, OpenOffice, and other free software. They make no secret of that.
• Free is still a very good price. Any student in any other country knows that it’s only free to them as a student. It won’t be free to their employer. It won’t be free if they launch their own business. Free software will always be free. Again, no big secret here.
• If you’re India, China, Pakistan, Poland, this is great news. Much of your software industry is off-shored development for the rest of the world. You want to be able to do work on Linux, Windows, or whatever the demand is for.

But what do I know? I’d love to hear your thoughts. Comment away.

It seems, as I surf on this subject looking for tidbits, I find myself often running into someone explaining that when it comes to open source, free doesn’t mean free. The meaningful point they are making is that “free” isn’t about money; it’s about freedom. If you use open source software your choices are nearly unlimited. For instance, if you want a change to the UI, you’re free to make that change. If you want the program extended to support some specific thing, you’re free to make that extension.

This is a real deal. I know among my techie friends, most of whom use a lot of closed source software, I hear complaints about both presentation and program process. (My son Ian, who is also a software engineer, is always saying “if only they had done that this way…”) With open source software, if you want something, and you have (or can hire) the skills, you can have it. You don’t get that without the source code.

But open source software is also free. That is, there are no licensing fees. You can install it, and run it, and extend it, and distribute it, and print it out and paper your walls with it if you want. It’s free.

I know there is an ongoing (and probably perpetual) debate about software TCO. The open sourcers say TCO is lower with open source software. The closed sourcers say TCO is lower with closed source software. Both make reasonable arguments, and both have lists of anecdotes that seem to support their position, but anecdotal evidence doesn’t prove a rule; it just proves a case. There’s one thing that there can be no debate on, and that is the initial cost of software. For open source software, that initial cost is zero, or at least nearly so.

I’ve heard the arguments that say you pay in the long run. I think those arguments are at least reasonable, if not entirely convincing. But what about the short run? You can’t pay in the long run unless you actually have a long run. Big successful corporations have money, and they may have a greater sense of value about their software if they buy it from a vendor they know and trust. (That greater sense of value may or may not have some basis in fact, but I digress.) But what about startup companies? Most startup companies are running on a tight budget. They are operated using savings, or venture capital, or small business loans, or whatever. But they are almost certainly working with a relatively static pool of cash at first. There is no regular river running into it. To them, the fact that open source software has no licensing fees may mean the difference between succeeding and failing. Every penny not spent on network software is available for other purposes, like marketing or R&D. The availability of open source software is a boon to these small companies.

Consider students as well. One example is math and engineering students, who often need access to Matlab for complex matrix calculations. By the time you tailor a Matlab installation with all the add on packages you need, you could spend well over $1000. That’s a lot of dough for a lot of students. On the other hand, Octave, an open source Matlab work-alike, is free. I’m involved right now in a highly technical project that requires Matlab. While I did eventually get a license from my client, I started out by downloading and using Octave. It’s free. And what about papers that are written by students? Sure, software companies offer some significant discounts to students, but OpenOffice is free. Free is a powerful word for students.

Sometimes, it’s good when free means, well, free.

As previously mentioned, Scott and I interviewed a couple of Microsoft Security gurus yesterday. As each interview went about 45 minutes, it’s going to take a while to distill down into a couple of posts. I should have something up on that next week. James Whittaker and Michael Howard are the two process/policy owners of Microsoft’s SDL. They were both enthusiastic and informative evangelists, not just on the subject of software security in general, but also on specific methodologies and processes that work to achieve more secure code.

I sent emails out to several project leaders and such on open source projects. I am soliciting interviews from open source movers and gurus. Hopefully, that will yield some interviews to shed light on some open source process. You know, it’s hard to write good software. It seems that distributing a development team geographically complicates that effort, making it even harder. It also seems that distributed management adds an additional challenge. Yet there are lots of good open source products out there. I’m anxious to talk to those who make them happen, and hear about both the challenges, and the processes they use to mitigate those challenges.

If you’re on the inside of something big and open source, I’d love to pick your brain. If you know someone else who is, I’d love to pick their brain too. Drop me an email at richard.bowler@gmail.com.

I ran across a blog today that offers “10 reasons for an enterprise to use opensource.” I think this list is typical of the kinds of “statement of faith” that you find from ideologues on either side of the open/closed source debate. While this one happens to be pushing open source, it could just as easily have been pushing proprietary/closed source. Here are some of the points, and the issues I have:

Opensource makes you responsible – When you choose the components yourself, you don’t have a vendor to scream at. Or, as is often the case, a whole heap of vendors to scream at, each merrily pointing all known fingers (and a few unknown ones) at everyone else. While you fume and stew.

Continue reading…

LifeBeyondCode links to GapingVoid and asks “Why are open source people not ultra-rich yet?”

Uh, they are. The founders of Google are ultra-rich. As are the founders of Amazon, and ebay. On the closed source side, Larry Ellison doesn’t seem to be doing too bad, Steve Jobs does think differently, with a $1.00 salary, but it’s hard to miss that 4.9bn net worth, and then there’s always the elephant in the net-worth room to consider.

The interesting thing about making it big doesn’t appear to be the underlying technology you build on, but the value that you add. Google did search better than anyone. Oracle made the database that was used by the human genome project. Ebay let you sell anything to anyone, anywhere. And Microsoft made the os-dejure for consumer apps, and even made the most popular productivity suite, ever.

Even looking at the “B” list of Flickr, YouTube, Adobe, Symantec, SAP, Veritas, MySpace, etc, they all add value well beyond their infrastructure to the point where their infrastructure isn’t even apparent. They also have considerable intellectual property, and at the end of the day, they all charge someone for something.

In my recent research I ran into a press release by the Collaborative Software Initiative (CSI), covered here by ZDNet. The recently funded CSI will hire a core team of developers to work on projects for multiple companies. The idea is to take a defined problem or system specification, and develop a product that addresses it. Companies who want the software will subsidize the development costs.

CSI, started by Stuart Cohen, the former CEO of the Open Source Development labs, is all about collaboration, but with a twist. The development process will be one using paid developers, and managed by paid management staff. Collaboration comes into play in a couple of ways. First, companies collaborate to fund a project (through CSI) to develop a software product these companies want. By collaborating through CSI, the per-company cost of the development will be significantly less than if it were developed internally. There is also an intended collaboration with a trade association. This is meant to ensure that the software developed complies with documented requirements and definitions already in place. Finally, the collaborating companies may make internal development staff available to work on the project through CSI management.

Interestingly, there is no guarantee that once developed, the software will be available under an Open Source license agreement. Rather, the software will be relicensed based on the wishes of the collaborating companies.

All of this is very interesting. It captures the spirit of collaboration at the center of open source development while bringing the strict process control of proprietary development to bear. While there are some details of this initiative that may not meet with the approval of ideologues on either side of the divide, it is nonetheless a creative combination of open and closed source development. I’m looking forward to following this company and seeing how well they can implement their vision.

One of the important issues facing software procurement decision makers is the availability and price of support. The TCO (Total Cost of Ownership) of a software system over the long term is more than the purchase price divided by the life of the product. Often, support costs far exceed original purchase costs over time. People who are responsible for making software acquisition decisions know this, and if they’re smart, they do support cost research before they procure.

Predictably, claims of lower support costs for open vs. closed source products abound on both sides of the argument. Open source proponents often claim significantly lower support costs for open source, based on the idea that support is a community affair. In his article, “Open Source Security: Better Protection at a Lower Cost,” Steve Schlesinger states “The open source model also lends itself to more vigorous and timely after-sale support from an active community of users, which in turn lowers the cost of support…” Similarly, Robert Westervelt notes in “Open source making its mark,” that companies planning to move to MySQL based solutions do so in part because they are “…lured by low cost of support and maintenance…” On the other side of the coin, in a TECHWORLD article by Phillip Britt, Joe Burton of Cisco (in responding to lower TCO claims of open source software) said that “…once the cost of support is factored in, Cisco’s system is competitive on price with open-source systems.”

Continue reading…

The 2006 ESJ Salary Survey shows that Windows and Linux admins get paid about the same amount.

I’m helping do Web research with Richard on this project, and as I come across interesting tidbits, I’ll post them.

Jeff Jones posts analysis of Vista vulnerabilities found in the first 90 days compared to RHEL, XP, SLED, and OS X. His results: Vista’s pretty secure.

Commenters offer the suggestion that other platforms just find and fix vulnerabilities faster, which is better, but Jeff says that’s not borne out by comparing mature OS’s over their lifetime, and that vulnerabilities found in the first 90 days are indicative of the total number of vulnerabilities which will be found.

Part of the process of this investigation, for me, is one of self education. While I have been involved at all levels of software development in closed/proprietary source environments, I have only casual, anecdotal exposure to the dynamics and specific processes of open source development. Consequently, I’ve been spending some time doing research to familiarize myself with open source history and the evolution of its methodologies.

When I first heard of open source software, it seemed the goal was to make software free. While the idea of free software appealed to me as a user, I derived my living from creating software that was sold for a profit, so I had mixed emotions. I liked the idea of community and collaboration that open source suggested, but wondered how a contributor could buy a cheeseburger when his collaborative stomach started growling. I assumed that contributors on open source projects were plying their trade for profit, and applying their skill to open source projects as their time allowed.

What I’m finding in my research is that the “freeness” isn’t really what defines open source software. The collaborative paper “Free Software / Open Source: Information Society Opportunities for Europe?” points out that there are other, non open source software systems that are available free. One prominent example is Microsoft Internet Explorer. Something else I’m running into is that open source software itself isn’t always entirely free. Companies are finding ways to make a profit on open source software by selling support, packaging, and system integration services, to name a few strategies. The web site www.opensource.org offers a definition of open source that consists of multiple points. It reads, however, more like a software license than a definition of a term.

What I’m discovering seems to be shaping up to this: Open source is still evolving. There are things that must be true (and will remain true) for a project to be open source. These include the right to free redistribution (without additional license requirements), availability of source code, and the right to modify and distribute derived works. Much of what I had assumed to be true about open source software either never was true, or is in a state of flux. Proprietary companies are in the process of bringing open source delivery models under the corporate umbrella, and figuring out ways to make a profit from open software. Doctor Dirk Riehle, in his article “The Economic Motivation of Open Source Software: Stakeholder Perspectives,” states that there are two types of open source software, Community open source, and Commercial open source.

One surmises that if commercial open source can marry the advantages of open source and closed source development together, we’ll all benefit. A good “for instance” is testing and documentation. Doing program testing and writing program documentation are not glamorous tasks. There tends to be low “organic” motivation to get involved with those roles. Because contributions are voluntary in “pure” open source development, it has always been a challenge to get necessary levels of testing and documentation. Red Hat and OpenOffice are two examples of companies with open source products who hire people to do these less glamorous tasks. These products then bring the commercial advantage of stringent testing and documentation to the table with an open source product.

Whatever else I learn in the next few weeks, I have already learned that this is a rich subject, and a fascinating one. I’m really looking forward to digging through it. I’m beginning to line up interviews with Microsoft folks, and should be able to begin those interviews next week. In the meantime, if you are involved in an open source project and can hook me up with interviews on that side of the equation, please drop me an email at richard.bowler@gmail.com. Thanks!

Before we dig into the details that will come out of individual interviews, let’s note some of the assertions being made by the proponents of either model. Both sides make statements about the superiority of their results. Many of these statements seem counter intuitive or even contradictory. For instance, Open Source proponents say their products are more secure because the source is available to everyone and gets more thoroughly examined for vulnerabilities, while Closed Source advocates say their products are more secure because the code is kept as a proprietary secret among a few developers. That’s like someone saying “my shirt is better than yours because it’s blue,” to which the other responds: “On the contrary, mine is better because it’s not blue.” Though we won’t try to individually debunk or sign on to any of these assertions in this post, it would be helpful to understand what they are as we go forward.

What are some of these assertions?

Continue reading…

As I begin this exploration, I’d like to start by briefly laying out my own professional history. I’m not an academic; I’m a builder. I began my career in 1976 as the only data processing (as they called it then) person in a small electronics manufacturing company. I worked designing and developing software for internal corporate use for about 5 years, then I made a conscious switch to development of commercial software for PDP-11s running RT-11 and RSTS operating systems. Once desktop computers became prevalent, I focused on software for those machines. My last 15 years or so have been spent primarily in engineering management roles, where I have been responsible for managing teams to deliver commercial software running in a Microsoft Windows environment. I have some gaps in my experience in that I have very little exposure to UNIX/Linux, and no experience developing software in an open source environment. I have no axe to grind, however, and I’m coming to this exercise with an open mind. Let’s see how open and closed source processes differ.

To gather the data I’ll need, I’ll be depending to a large extent on interviews with development professionals. I expect Microsoft to give me access to product managers and developers, and I hope to convince other closed source companies to give me similar access to their staffs. I’ll interview open source managers and developers as well. I’ll be focusing roughly on the following questions:

1. How are features for the first or subsequent versions of a product determined?

2. How are features architected and designed?

3. How does a feature go from an idea to something being coded?

4. How do all the “ity’s” end up in the product (security, quality, reliability, scalability, etc.)?

5. How does documentation and localization get done?

6. How are project schedules formed and tracked?

7. How are projected release dates communicated to the public?

8. How does a product transition from Beta to release?

9. How do bugs get reported and fixed?

10. How do users get access to the source code?

11. What do users do with the source code?

We all know that processes differ from team to team, regardless of whether the code is being developed using open source or closed source methods. Since that’s true, I’ll need to access several different teams on both sides of the issue so that I can identify broad trends and attributes of the two approaches to development, and avoid drawing conclusions based on the idiosyncrasies of 1 or 2 teams. I’ll need your help with that.

Please let me know which companies you would like me to examine on the closed source side, and which projects on the open source side. If you are personally involved in a development project of either type, can you help me get access to others on the project? I’ll do a condensed conversation dump to this blog after each interview, and I’ll identify the person I interviewed as well as their company or project affiliation. If you think your process is great, let’s get it in the mix.

One recurring question in the IT marketplace today is how does a proprietary software development model compare to an open source development model? What are the trade-off decisions that a software vendor or a customer makes when comparing the two models?

In order to address these questions, Microsoft invited Scott and Sean to look into the process, benefits, and high-level trade-offs associated with proprietary & open-source software development models, which includes not only the development process, but the flexibility, vendor accountability, ecosystem benefits, etc…

Scott and Sean are very excited to be a part of this dialogue to discuss the differences between software developed using closed source and open source development paradigms.

They both have been engaging with industry subject matter experts across various companies to gather information on open source and proprietary software development processes. To be successful, I’ll also need to engage with you. Whether you are involved in closed source projects, open source projects, or both, they would like to hear your thoughts on the issue. Do you love one and hate the other? Why? What do you think are the relative strengths and weaknesses of the two paradigms? As the investigation continues, they also hope that the community will help them refine my findings and help make the project successful.

For the sake of this project, we will define a few ground rules:

Scope of the project

This project will examine the stages of the software delivery lifecycle in an open source vs. a closed source environment. For the purposes of this project, we will define open source software to be software where the source code is available for inspection, modification, and distribution. Closed source software is defined as software where the source is available to few people or organizations, typically the vendor that created the software and possibly their partners under tight non-disclosure agreements.

The findings will be used to highlight the differences in methodology and processes related to quality, security, support etc in each phase of the lifecycle.

The project aims to examine the following questions:

• How does the idea design differ in an open source and a closed source environment?
• How does the engineering process differ in the closed vs. the open Source Scenario?
• How do the two ecosystems differ and what are the implications?

The following aspects will not be examined:

• How does the Software development life cycle of closed source and open source software differ?
• Which development model is better?

Output and Methodology

We have set up this forum to facilitate discussion of the effort and will be posting transcripts of our discussion with various experts.

The primary audience for the blog and overall effort are software vendors or customers seeking to better understand the trade-offs associated with commercial closed source (e.g. “proprietary”) software and commercial open source software.

The findings will be based on Community feedback on the blog coupled with:

• Interviews with key development staff for the selected closed source and open source organizations, and document (via this blog) similarities and trends in the software delivery process in each of the development methodologies.
• Findings from additional public sources like published interviews, whitepapers, newsgroups, blogs etc.

We will make frequent blog posts with raw findings, allowing the community to comment, refute, or offer supporting evidence regarding the findings. We will also produce and periodically update readers with the aggregate results of the findings. Companies or members of the community performing open and/or closed source development are invited to participate. Microsoft and other software development firms may make employees available for the investigator to interview, and members of the open source community are likewise encouraged to be interviewed to facilitate the investigation.

Now that we have the ground rules, let the discussion begin!