At the end of the first quarter of 2012 there was a slight fluttering through the wind chimes of business journals,

technology news sites, Google plus, twitter, and Facebook: Red Hat, the producers of the Red Hat Enterprise Linux (RHEL), and sponsors of the Fedora Project, had become the first billion-dollar open source software company. Yes, that’s “Billion”, with a ‘B’. Yes, that’s “open source”, as in publicly available and changeable code. Perhaps this deserves a finer point to be put upon it: A company, based on a product where all code was available to the public, was able to monetize their product and reach a critical mass of a billion dollars.

A typical profit-centric analysis could say that this should not be possible. Never mind the business plan that Red Hat uses to leverage support licenses for their product, the simple fact that software available to everyone could generate such staggering revenues has spun the software world on its head. No longer is the cheeky alternative operating system of Linux confined to hobbyist systems and mailing list discussions. This is a new era of software development, one that starts with the user, and ends with the user, but it goes well beyond the operating system you use. The open source software world is filled with projects for everything you can imagine, and all the code is available for free.

So, what’s a Business Analyst to do in this brave new world?

As Business Analysts everything is supposed to be tied to money. Would adding this new feature increase the value of our product? Will that translate into revenue dollars? Would support costs decrease? These are all questions that the Business Analyst thinks over whenever they consider the requirements, and eventual solutions, to the problems a business will face and the software it creates to solve those problems. But when you remove the money from the equation, where does your guidance come? Even though the dollars are removed from the equation, the same problems still stand: users need to get things done, programs need to accomplish goals, and deadlines need to be met.

This gives Business Analysts who may be operating in an open source environment just the kind of wiggle room they always wish they’d had in a business environment: creative freedom. When you remove the money from the equation, you’re only left with 1: What can you accomplish with what you have? And more importantly 2: What exactly do you want this thing to do?

Rather than assigning dollar signs to goals and tying success to them open source projects are most concerned with completing their product concept. This simple statement of what the product should be would be the basis of future conversations in determining scope and work to be done. It’s these conversations, once documented in requirements that push the development throughout the project, as it is the very idea that is the lifeblood of an open source project.

Every open source software project starts as an idea. It’s this spark of imagination that can do anything from creating something openly available that may not have been available to the public before freely, such as a CD burning program, or attempt a revolution of the desktop, like with Linux operating systems. However, these dreams still can be assigned goals, and these goals can be analyzed, quantified, and accomplished. These goals can be spelled out by Business Analysts.

On a typical project I would use a Business Objectives Model to trace the goals of a project to dollar values. As we’ve already discussed, this isn’t all that valuable in an open source environment; essentially your objectives are going to come from your stakeholders minds. Who are the stakeholders? Well they’re the people with the ideas, and they are the direct users themselves. You can sit down with the steering committee for an open source project and chart out their goals and aspirations like you would with a typical revenue-generating project. Those needs will come out into business-objective-like statements. Those statements can be used to drive capability and feature discussions, and continue on into written requirements; an actual plan for the project, mapped out, written down, consumable, and testable. Open source projects are only limited by the volunteers that they have, and the requirements can be scoped according to the availability of development resources for a project. It’s that simple.

This level of planning does not necessarily take place in a typical Open Source project, at least in the sense that it is used today in the business world. Though, it would be a small matter to implement a requirement methodology on an open source project. Many open source projects go into planning with an engineering-driven attitude which, while functional, can leave a lot to be desired in the way of ensuring completeness of vision. Often what a project looks to accomplish can snuff out the small force of volunteers available to them, and a lack of documentation of vision can make it difficult for interested volunteers to know how and where they should participate to make the project successful. A clearly defined initial scope tailored for a minimum viable product and the resources available could substantially increase the success of an open source effort.

Past the planning effort and defining of scope the requirements created to help drive the vision of the project can then be used after development has begun to create test plans beyond normal programmatic unit testing, and ensure that the original objectives of the project are being met. Clean test plans can be produced from the documentation that the project creates up front in the planning stages, just like in a business environment.

Is it likely that the open source movement would adopt requirements methodologies into their normal planning and procedures? Perhaps not, given that business analysis is still a fledgling field, and many engineers are still unconvinced. However, while it is easy to dismiss those who point to scope and objectives as merely pounding sand, it’s almost always the Business Analysts who can tell you exactly why a project failed.