GLOSS

Today's columnist is Christopher Sean Morrison from BRL-CAD. He writes:

"If the Trojan horse had been made of glass, Troy never would’ve fallen."

Scott McNealy, Sun Microsystems Co-founder

High atop an office building on the outskirts of Washington D.C., a bunch of U.S. government software developers from around the country got together this week with a common vision: more open source. I was among this collection of geeky, coffee-drinking, sandal-wearing patriots, most of whom work directly or indirectly for the U.S. Department of Defense (DoD) where we're part of a grassroots movement to promote the use and development of open source by government organizations. This was the second working group meeting of the Mil-OSS community, where a collection of civilians, military, and contractors gathered to discuss topics of policy, philosophy, legalities, life, liberty, and the pursuit of open source. The wealth of insights, planning, case studies, recommendations, and even a bit of coding on the spot are helping to establish a growing trend towards the establishment of GLOSS: Government Libre Open Source Software.

From the traditionally secretive military industrial complex has blossomed a belief that the old way of doing business is fundamentally changing. It's changing fast. By necessity, to remain competitive and productive, development is becoming more open, dynamic, collaborative, and social. The open source proponents working within the DoD have been laying a foundation to facilitate change not only within the military, but throughout all branches of the U.S. government. This change is reaching a tipping point as more and more agencies adopt strategies for managing open source software, realize how much open source they already use, and observe the benefits being garnered by others that adopt and promote Free Libre Open Source Software (FLOSS).

So what makes GLOSS different from FLOSS? Why the GLOSS vs. FLOSS distinction at all? While it is very true that most of the same principles of open source apply, governments around the world are faced with unique challenges as participants in an open source arena. A primary distinction is one of intellectual property and rights management. Most governments must abide by a completely different set of rules and regulations than those that apply to individuals or businesses. Most governments are not in the business of competing with commercial industry. To the contrary, many are explicitly prohibited by federal statutes to do so. The legalities can be considerably complex to navigate.

Consider a "simple" matter of copyright. In most countries, someone who writes some software automatically has a set of intrinsic rights as the author or creator of an original work. One of the most basic intellectual property rights is the ability to authorize others to use your original work on agreed terms. Unlike the fair use and fair dealing doctrines that attempt to ensure that individuals have some basic protections of their own as users, copyright holders have considerably broader rights on their work in part due to protections ensured by the Berne Convention. The Berne Convention is an international agreement signed into law by most countries to help ensure that copyright protections are completely automatic in most countries, without the need to register or notify anyone. When a government produces a work, however, different laws come into play and can vary wildly from country to country.

For example, the United States considers works by U.S. government employees as being not entitled to domestic copyright protection. The U.S. government can claim copyright on their works in other countries, just not with their own citizens that paid for that work. To make matters more complicated, the U.S. government can be assigned copyright, but the circumstances of those rules are governed by a body of federal acquisition laws with numerous complexities. In Canada and other commonwealth realms, the government does make a claim of copyright -- a "Crown copyright" -- on works produced by government employees. The rules can be particularly complicated and vary substantially from country to country, but you get the idea.

So with all of that complexity, why does GLOSS even matter? The reason is simple. Governments around the world employ a massive number of people and affect the behavior of an even larger proportion of industry. Well over a million people work for the National Health Service (NHS) in the United Kingdom. More than 1.6 million people work for Indian Railways, the state-owned railway company of India. At nearly two million civilian employees and 2% percent of the entire national workforce, the U.S. federal government is the nation's largest employer with a majority working for the DoD (and that doesn't even include the Postal Service, intelligence agencies, or government contractors). Around the world, governments are spending time and money developing massive amounts of software, but in only exceptionally rare contributions are those released as open source.

The past couple years have been particularly exciting for the Mil-OSS community as a new trend has been emerging within the U.S. government to shift more towards open operations. On his first day of office, January 21st, 2009, U.S. president Barack Obama gave guidance to the federal workforce that a presumption in favor of disclosure should be adopted for Freedom of Information Act (FOIA) requests. That was immediately followed by another memo calling for "an unprecedented level of openness in Government." That transparency memo reads like a HOWTO for directly supporting open source with visionary claims that:

• Government should be transparent
  

• Government should be participatory
  

• Government should be collaborative
  

This guidance, while long overdue, ultimately reinforced and helped accelerate a trend towards open source that was already under way. Open source is in pervasive use throughout most governments. Like many corporations, governments rely on popular open source software products such as Linux, Apache, Bind, GCC, Firefox, MySQL, Kerberos, and dozens more as part of critical IT infrastructure. The accelerant has been notable direct contributions to open source by government agencies releasing their own source code as open source software.

Examples of open source contributions include NASA's extensive suite of open source projects, the U.S. Army converting BRL-CAD into an open source project, the NSA developing SELinux, and the White House releasing numerous Drupal modules after deploying a new website built on Drupal. Many departments and agencies within the U.S government now have one or more notable open source projects.

There still remain many challenges down the road ahead. Most governments are terrible at interactive participatory communication, collaboration, and transparency even after directed to be that way. Individuals can help, however, by engaging agencies with specific requests and attainable goals. Canadians can file a request for access to unclassified records under the Access to Information Act. If you're in the U.S., you can file a FOIA request for specific data. With source code in hand, citizens are empowered to help their governments adopt a GLOSS perspective on their works by releasing it for them. GLOSS will become a major player across the diverse FLOSS ecosystem.

Interdisciplinary Lessons

The August issue of the OSBR is now available in PDF and HTML formats. The editorial theme this month is "Interdisciplinary Lessons" and the authors include:

Teresa Jewell, a researcher at York University, recounts lessons from the history of the feminist movement and applies them to the challenges faced by open source communities.

Mekki MacAuley, Principal of OSStrategy.org, reviews select lessons from other disciplines, applies them to open source contexts, and suggests approaches to uncover further lessons in other fields.

Michael Ayukawa, Founder of Cornerportal, and Julie DuPont, Cultural Planner for the City of Ottawa, describe an ecosystem approach to multidisciplinary event organization and facilitation with the aim of solving existing and emerging problems, and strengthening Ottawa’s position as a creative city.

James Makienko and Leonard De Baets, researchers from Carleton University, describe a project to create a deal development platform by extending an open source customer relationship management tool.

Frank Horsfall, Founder of EnTeraSec, uses a real-world case study to describe Bloom, an open source relationship visualization project for complex networks and business ecosystems.

The editorial theme for the upcoming September issue of the OSBR is "Keystone Companies" and submissions are due by August 15th. October's theme is "Sales Strategy" and submissions are due by September 1st. Please contact the Editor if you are interested in making a submission.

The Development Commons Approach

Today's columnist is Julian Egelstaff from Freeform Solutions. He writes:

There's this myth that open source software is built by an army of volunteer programmers around the world who all collaborate in fixing bugs, adding features, and generally raising the bar.

It's true for some large projects, like Linux and Firefox. It's not true for the vast majority of code that has been released under open source licenses. If you count all the projects on major open source code repositories, the overwhelming majority have only /one/ developer.

At Freeform Solutions, we have a mission to help not-for-profit and public sector organizations use technology more effectively. We advocate for open source, as one way to achieve that goal. We use and promote some software that does have large groups of programmers. Drupal is a perfect "middle weight" example. It's no where near as big a project as the top open source solutions. But it is a very successful project, with people supporting and working on it around the world.

But if promoting open source comes down to advocating that people use the best mid-sized or larger open source projects, then all we're really doing is promoting successful open source "products" as alternatives to proprietary products. We don't simply believe open source products are competitive with proprietary counterparts. We believe in the power of the underlying principles of open source. We believe that it empowers people to have access to software's source code. We believe collaboration and sharing makes better software.

So if we truly believe that, how can we extend those benefits to the organizations we serve, who can't collaborate at a technical level? This is an ongoing challenge and we have come to label our solution the "Development Commons".

The Development Commons works at a number of levels. Sometimes, we view it simply as the activity of providing a way for the different organizations we work with, to work with each other to solve common problems. We act as a connector node in a network and bring people together so they can benefit from each other's insight and experience. Sometimes we view it more technically, as the activity of enabling the participation of our non-technical clients in the technical business of contributing to open source software.

At this technical level, Freeform Solutions is essentially acting as a proxy developer for the organizations we work with. They cannot engage in the code themselves, but there are benefits to be had if their experience with the software can be translated into new features and other improvements. At the end of the day, this requires commit access, either directly or indirectly. You can't participate in an open source project if you don't have a way of sharing your code.

So it's no surprise that our most extensive Development Commons project, at a technical level, is the Formulize data management and reporting system. We are the lead developers on Formulize and guide the roadmap for the software, so there's no barrier at all to getting code changes into the software. We have used this position as an opportunity to translate the various needs of our clients who use Formulize, into new features and improvements that benefit all users. Instead of adding a feature to meet need X of a particular client, we add the capability of meeting needs like X to the software, and then everyone benefits from that one organization's contribution. This is a powerful way to facilitate contributions from non-technical participants, who often have the most experience in using the software, but the least ability to engage in its development.

After six years of development, Formulize is now on the cusp of its fourth major release. Over the years, many organizations have contributed in large and small ways to the project, sometimes as more passive users simply making their needs known, sometimes as active sponsors of major features. The cast of characters is diverse and international, ranging from science outreach organizations in Canada (Let's Talk Science and Actua), to child welfare groups and projects (the Ontario Association of Children's Aid Societies and the Maltreatment and Adolescent Pathways research project), and to non-profit associations in other countries (the Australasian College of Sports Physicians and the Frontier Airlines Pilots Association).

None of those groups has the technical capability to develop software. But through a Development Commons model, they have all contributed to the creation of innovative web-based software for collecting, managing, and reporting on data. Their subject areas are diverse, but their technical needs have enough in common that they can collaborate through a well-managed development effort to meet their individual needs through shared action.

The latest organization to join the commons is among the most surprising of all: Microsoft.

Perhaps realizing that desktop dominance will never be the one true path to monopoly that it once was, Microsoft has been ramping up its profile in the open source community as much as possible in the last few years. Earlier this year, representatives from Microsoft Canada approached us about including Formulize in their "web platform installer", basically a simplified way for people who use Microsoft's web server software to install and use web-based applications. If you've ever installed Wordpress through one click in your ISP's control panel, you know what I'm talking about.

The beautiful thing about open source licenses is they make it possible for anyone to contribute, and they require that anyone who does, plays by the same rules. The old "embrace, extend, extinguish" tactics that Microsoft has used in the past can't work against proper open source licensing. It's a level playing field and anyone is welcome to play, to the benefit of all.

We are very excited to see what directions lie ahead. The fact that the cast of characters keeps growing in different directions is a good sign. Version four of Formulize is a major consolidation release that caps six years of Development Commons work. We see it as validation that open source methodologies themselves can provide value when you find ways to engage all kinds of participants, even without an army of developers.

References:

• Formulize
  

• Number of F/LOSS projects by team
  size:
  

  • Freshmeat
    

  • Free Software Foundation
    

  • Rubyforge
    

  • Objectweb
    

  • Sourceforge
    

A Different Approach to Thin Client/Thick Client Deployments

Today's columnist is Carlo Daffara from Conecta. He writes:

I have had the opportunity to work in many different migration experiments in the financial, educational, industrial, and health care sectors. The reasons for migration are varied, but the single strongest motivator is usually: "let's save some money." Some migrations succeed and some do not, or at least not completely. All of them are difficult.

Yes, all of them. Even with the best practices (and we have written some), the effort required to migrate is always substantial because you are replacing something that works with something that may or may not work better. Humans estimate risks poorly and in IT, the devil you know remains the preferred one, even if you have to reboot that devil daily to make work. A CIO faces a conundrum that is similar to a roulette player. Where the roulette player says, "I have lost so much, I can't stop now or I will lose everything!", the CIO says "we have worked so hard to keep this house of cards standing, we can't stop now or all that work will have been for nothing!"

In reality, our research has shown that it is usually much better to avoid trying to supplant something that exists and works; it is much better to invent something new and different. The huge success of the iPad is not due to the fact that it replaces netbooks, or notebooks, or PCs: it is a different media. Like TV didn't replace radio but created a different channel, you have to go outside the basic competition model to find a market that may be much easier to grasp.

A fitting example may be the mobile environment, where Android surged rapidly by filling the need for a low-cost, easily sourced operating system for mobiles, allowing personalization and adaptation. These are fundamental differentiation factors since most phones share similar hardware functionality. At the same time, I believe that by simply looking to replace Windows on the desktop is in itself a uphill battle. This doesn't mean it shouldn't be done, but it may be easier to find other routes.

One such route is to create an intermediate level between thin clients (easily managed, high structural cost, low flexibility), virtual desktop infrastructure (VDI; moderately easier to manage, high structural cost, high flexibility) and traditional PCs (difficult to manage, high flexibility, low structural cost). The problem with "high structural cost" is that performing an adoption or migration experiment requires you to bring in the whole enchilada: virtualization or remotization infrastructure, server, licenses, and a great deal of effort to join all the dots together. One of the reasons for the great success of the PC was that adding one more PC was possible with limited costs – basically the cost of the hardware and software itself, and some configuration work. A good example of the costs and infrastructure necessary for VDI can be found here, to which project management, licenses, and consulting work must be added.

Also, the recent trend towards remotization (such as Terminal Services and Citrix) and VDI is encountering an unexpected difficulty: the rise of Web applications that are inherently location-transparent and work perfectly on the client. Rich interfaces, Flash, and Java applets place high demands on the server and are best executed directly on the client. So, you pay extra to use software like Citrix HDX that basically moves some of the execution work back to the client. And, if you need "detached mode" and have a large enough hard disk, you can use local virtualization and have the virtual image streamed to your PC for local execution – at a price, of course.

What I propose is a different approach: a mid-zone between a rich, full-install client and a thin client. Most applications would be executed locally, particularly the important ones such as the browser, OpenOffice, and conferencing applications. Also, remotized applications could be accessed and, if necessary, could execute Windows applications almost seamlessly using virtualization with tools like VirtualBox or KVM. The VM image of Windows could be stored remotely at merely the cost of storage and could be replicated in multiple sites using a WAN-compatible system like XtreemFS. This would ensure any change to the image is transparently replicated to another office for nomadic users, allowing them to execute those applications that are not portable or web-accessible.

With this method, the install image can be very, very small. It also means that you can store it in a small USB key and the user can try it without having to install anything. If they like it, they only need to image their hard disk and move it to a remote VM. They can live off that USB key, which can travel with them anywhere. Windows remains, but as more and more applications become web-enabled or transported to Linux, its role becomes smaller and smaller – up to the point where it can disappear.

I believe that this can be a worthwhile experiment. In fact, as a spin-off of our EU research activities, I started doing something similar a few months ago with a fully open source project called EveryDesk. I hope that other may find this approach interesting – and join us in making it useful.

Search Engine Optimization: Plug Your Nose and Fix Your Site

Today's columnist is Emma Jane Hogbin from HICK Tech. Emma writes:

This week I was almost completely consumed by search engine optimization (SEO). It's the topic for a chapter in my new book on building Drupal websites and it's the subject of an SEO class that I'm teaching at the beginning of August. As a result, I was studying the competition and comparing search results for phrases like "php drupal" and "php drupal help" and I was obsessing with click-through and conversion rates.

And then I got side tracked.

Using Google, I looked up the following terms:

• free graphics application

• free graphics software

• free graphics program

• free graphics editor

If we compare the results of these four searches we'll see most people use the term "software" with occasional forays into "program" and that the most popular regions for any combination of these terms are from India, South Africa, New Zealand, and the UK.

GIMP ranks well in all four search phrases, but only the first link yields a top-ten result for Inkscape. What's up Inkscape? Why aren't you in the top ten and how can we make you do better? SEO to the rescue! Before you get covered in hives and think that SEO is just for marketing wonks, let's take a look at how all projects, products, and businesses can benefit from a little bit of site optimization.

What is SEO?

One of my top-favourite SEO specialists over at RankStudy defines SEO as "the process of enhancing both the content and the reputation of a Web page in order to improve search engine rankings and meet your top prospects at their immediate point of need." This definition gives us four key areas of focus:

1. Content: this is the quality of the words and phrases you use on your site, including the semantic value you give that content. Headings are more important that plain text; page titles are more important than headings.

2. Reputation: this is the quality of incoming links, including the key phrases used in the link text as well as the popularity of the sites who link to you.

3. Top prospects: who's got the potential to become a user, a developer, or a raving fan that gives presentations at user groups? You want to create content to attract the people who will do the most for your project.

4. Match visitor needs to site content: this is the pairing of your "most wanted outcome" with your visitor's "point of need." If your visitor needs a tutorial to help them with their user group demo and you want them to become a developer there's a mismatch between what you want and what your visitor wants.

Seeing Your Site Through a Search Engine's Eyes

Every single page of your Web site should have a purpose with an intended audience and a most-wanted outcome. Whether you're trying to attract users or developers, take a good look at every page on your website and ask yourself the following questions:

• What's the point of this page? Who needs to read it and what should they do after reading it?

• What are the key phrases or keywords for this page?

• What's the Wordle for this page?

• Does the Wordle have the key phrases it needs for the right type of visitors to find this page?

• What are key search phrases that visitors are currently using to get to my site? (If you're not using some kind of analytics package, shame on you! If you're looking for an open source alternative to Google Analytics, take a look at Piwik. Their demo looks amazing.)

Find out what keywords your competitor sites are using. You can "view source" of individual pages to look for the meta tag that holds the keywords for that page, or you can have Google scrape out the keywords they think are important using one of their free tools:

• Keyword Tool for Google Adwords

• Google Search-based Keyword Tool

Not only will you get a list of terms, but they'll also tell you how popular the term is and how heavy the competition is for that keyword. Find terms that are high on search volume, but low on competition.

Need even more ideas? Try the suggestions that Wordtracker gives you.

Making Your Site Better

You should now have a huge list of all the key phrases you should be using and it's time to apply them to your site. Here are the steps to getting your site ranking highly in search engines so that you can find more top prospects at their point of need:

1. Add keywords from the mega list to relevant pages.

2. Give your pages unique titles and juicy keywords. Inkscape: this is a cheap win for your site. Make those page titles unique and I bet your key phrases will (almost instantly) jump way up in the search engine rankings.

3. Add markup to content to improve the semantic value of your keywords. Break your page into content that has headings and otherwise emphasizes important text.

4. Monitor your site's stats for search phrases people are using to find your site.

Give it a week or two and then re-test your search engine ranking for the key words and phrases that are important to your top prospects.

With these few simple tips, any open source project can help propel their website to a higher ranking in search engines. It will help you attract new users and keep your existing users happy.

Making Open Source Profitable

Today's columnist is Sean Morrison from BRL-CAD. He writes:

From economics, profit maximization is a process used to maximize a return on investment. It's a process that looks at sales prices, production costs, and other factors in order to find a sweet spot where you make the most with the least. Profit, in its most basic form, can be described with a simple equation:

Profit = Sales - Cost

That's all good and well, but what does it have to do with free/libre open source software (F/LOSS)? For many free software developers, the mere idea of making money is an affront to their ideals. Business journalist Dana Blankenhorn of ZDNet notes in The open source tea party that there are drastic differences in what motivates contributors to F/LOSS: "In its starkest terms there is a divide between idealists and realists, between those who see FOSS as a creed to be adhered to and those who see it mainly as a business model, a route to profit."

But this isn't about money. Especially for software that is freely (in every sense of the word) and openly shared, talking about sales and profit may seem a bit peculiar. Developing an open source community, however, has substantial parallels with developing a small business and many of the same concepts and tips still apply. The main difference is a translation of terminology.

So what does profit mean? In general economic terms, Wikipedia tells us that profit is the total revenue (i.e., the sales) minus the total expenses (i.e., the costs). Except we're still in unfamiliar territory. Open source projects are not usually expressed in terms of monetary value. Open source projects are compared with a myriad of metrics such as popularity, project vitality, code metrics, and overall utility of the software itself.

That being the case, consider what profit means to a business. For commercial industry, a successful business is a profitable business. A successful open source project, however, is one that offers something of sustainable value. Therein we begin to see how the same equation can be applied in a more generalized form:

Profit = Revenue - Expenditures

Revenue for open source is value coming into the project and value is derived by interest in the project. Value comes from the utility of the code itself; it comes from the open source community around that project, its developers, and its users. Growing the community, increasing downloads, and making improvements to the source code represent an increase in that project's total revenue.

Expenditures for open source is a little more tricky as the software itself is free (as in beer and freedom), but there certainly are still "costs" as there are expenditures of time and effort. In terms of development, there is effort expended publishing releases, maintaining infrastructure, developing the code, reviewing contributions from others, and keeping the code maintained. The community at large spends time learning the software and sharing their knowledge with others.

The open source software movement may be relatively new, but running a small business is not. Evaluating profit, increasing revenue, and decreasing expenditures are terms commonplace in business. It would be highly disadvantageous of growth-bound projects to ignore the existing wealth of business resources available. One such resource is the non-profit SCORE Association which focuses on providing free business mentoring services.

SCORE provides a plethora of resources and advice for growing business that can be applied to most open source projects with a simple translation of terminology. For example, their top five categories for improvement include: 1) improving your web site, 2) building a local presence, 3) preparing for growth, 4) conserving capital, and 5) enhancing sales. All of those can be readily described in terms of our aforementioned profit equation.

Improving a web site amounts to increasing revenue by attracting new contributors while reducing expenditures through improved support. Their tips on building a local presence and preparing for growth aim to reduce project expenditures by leveraging outside help, delegating responsibilities, and recognizing people that consume more than they contribute. Conserving capital is particularly interesting as a project's developers, community, and code are open source capital. Included in their tips on conserving capital are suggestions of being frugal with developer resources, knowing your users, not reinventing the wheel, and encouraging reuse. Enhancing open source sales (i.e., value coming into the project) refers to improving user awareness and education, cultivating new contributors, being persistent, and demonstrating your project's value to the community at large. The breadth and scope of applicable sound advice is abundant.

Why are you involved with open source? Maybe you are looking to turn a software asset into a commodity that is hopefully updated, maintained, and improved by a legion of contributors around the world. Perhaps your goal is to develop or even commercialize some open source asset. Or maybe you've developed useful code but since it's not your core business, you realize that there is still a potential public relations benefit.

Reduce your open source expenditures. Improve your open source revenues. When looking for ways to make open source successful, increasing your open source profit is a great place to begin.

A Modest Proposal: A Structured Tax-Exempt Structure for Corporate OSS Development

Today's columnist is Carlo Daffara from Conecta. He writes:

One of the most common observations in the open source marketplace is related to the low level of contributions by companies, especially small and medium sized businesses, to the projects behind the open source software (OSS) they use within their embedded systems or as part of an internal IT infrastructure. Looking at the Eclipse Foundation, one of the best run open source projects, it is possible to see that most contributions are from large companies that use Eclipse as a basis for their products or from open source companies that are aware of the strategic importance for code contributions to OSS projects.

What is missing is the large number of companies that may be interested in contributing and who perhaps are already sponsoring some internal developer's work on the project. However, they are not able to structure their contributions in a formal way. The reason is threefold: knowledge, legal, and economics.

Knowledge: most companies are unaware of the fact that they can contribute back or do not know how to do so. Maybe an internal developer is able to submit patches, but the company itself does not understand how to fully engage with the open source project. For this reason, many contributions are from individuals using a company email. Company managers are often unaware of the use of OSS inside of their own products or infrastructure, and do not understand what advantage may be obtained by giving back to the project. In fact, most companies are limited in the first step of the OSS adoption ladder identified by Carbone and moving up the ladder from "use" to "contribute" is a much rarer step.

Legal: companies are often wary of backfire from an "official" contribution. They fear that internal intellectual property (IP) may be revealed. Some licenses provide implicit patent granting, which may limit the ability of a company to ask for licensing fees later. Some companies avoid this scenario accurately; for example, some of the contributions to OSS by Microsoft were developed by external companies that held no IP under contract from Microsoft, and were released in an indirect way.

Economics: why should a company contribute? What economic benefit can it bring? Unless there is a clear business advantage, most companies will not face the risks and costs of contributing code, and prefer taking the "developer did it" approach.

I would like to propose a blue-sky experiment: a clearinghouse for code contributions. It can be imagined as a traditional software development company, but under non-profit and tax-exempt status. This would be similar to the Mozilla Foundation, but would aggregate development activities from many different companies and covering a wide spectrum of projects. The clearinghouse can accept tax-exempt donations, clearly marked towards a development objective, and visible through a project dashboard, such as the one used by the Eclipse project. The clearinghouse can then parcel the work out with a bounty system, if the work is small, or directly by paying the developers of the original project for the activity. This way, the OSS project can receive an immediate benefit.

The biggest difference between current structures would be the:

• coverage of a large number of projects, increasing the sustainability of the clearinghouse itself


• legal coverage, as the development would be done by a third party, not impacting any potential IP held


• efficiency of the structure, reducing the ramp-up effort for internal developers to become proficient with the source code itself


• tax-exempt status of the donation, providing an economic benefit on top of the increased efficiency of open source development

Such a structure can be made in a relatively simple and cost-efficient way, one per continent to simplify the legal process. In my opinion, this can be a first step towards increased participation by those companies that now use open source, and still are unaware of the potential impact of contributing. We tend to overestimate the impact of large contributions and forget that, for example, in the Linux kernel 25% of the change sets are from unaffiliated developers, the single largest group. If we can turn at least a small part of that 25% into paid services under a tax-exempt umbrella, we radically increase the economic market for open source services.

Artifacts

Today's columnist is Emma-Jane Hogbin from Hick Tech. She writes:

I have the most interesting conversations while at open source conferences. A few weeks ago at CMS Expo I had a great conversation with Jeff Eaton about open source as it relates to things other than code. I'm not sure where Jeff came up with the phrase, but he recently realized that many of the best third party contributed Drupal modules are "artifacts of paid work". Unlike many open source projects where a developer "scratches their own itch", much of the Drupal ecosystem of code has been built by people who were paid for their time.

While this could open up the conversation to all kinds of interesting comparisons and rebuttals and agreements and disagreements, let's head off in a different direction. Contributing artifacts has made the Drupal code ecosystem incredibly healthy and a wonderful place to dive into when you are looking to deploy a Web site with a shoestring budget. There are, however, two main problems that we've not yet solved: i) designs can never be artifacts; and ii) training has no residual artifact.

For the most part, code is generic enough that it can be easily dropped into a new design and re-used without compromising the brand of the original site. This is not true for design. You can't design a new theme for Drupal and then drop it into the community for others to re-use. Design is not an artifact. Design components may be artifacts, but there is currently no way to store these artifacts on Drupal.org. Contributed components relevant to Drupal include Lullabot's icons (Lullacons) and Top Notch Theme's snippet and style repository. The Lullacons can be used outside of the Drupal project, but the theme snippets are only relevant in very specific use cases.

To help designers share their work in the Drupal community, we need to define what an artifact is to a designer. Is it a font? An edge style for a div on a page? Is it a set of icons? What are the abstracted parts of design that, like the contributed code, can simply be artifacts at the end of the design process? With the artifacts defined, we then need to find a way to give as much weight in the Drupal code hosting system to these design artifacts as we give to code artifacts.

The second challenge is that of training. artifacts of training may be the "learning objects" used to train students. Smart (or is that lazy?) trainers will find as many objects as they can from within the free Drupal resources. Teach developers to use api.drupal.org and you have trained them for life. But these objects, or artifacts, do not teach people how to choose a few relevant modules from the thousands that are available. They are about as useful as the .tar.gz file containing a contributed module without the Drupal core code base. To make training work, you need to have a curriculum with defined learner roles and tasks and progression. Many companies (my own included) train people on how to use Drupal. Due to the pace of change in the Internet world, it is unlikely our curriculum will ever become an artifact.

There are projects within the Drupal community that are looking to collaborate on an open curriculum. The Curriculum and Training Group has started meeting weekly on IRC. The Ubuntu project has an equivalent group. But these curriculum projects are not simply releasing artifacts of their paid work---they are trying to generate something for others to use. This changes the dynamic of the participants substantially. For the professionals who train others for a living, what is the incentive to participate? Their own itches are being scratched each time they teach their curriculum. If they release their artifacts, will they lose students? The risks to sharing for the paid professionals is an interesting challenge that I do not have an answer to.

Are you a designer that can list artifacts of design? Help me share the leftovers of your paid work. Are you a paid professional with an open source curriculum, or at least freely licensed curriculum? How did you do it and how has it affected your business?

Speaking with an Open Source Tongue

Today's columnist is Christopher Sean Morrison from BRL-CAD. He writes:

"A slip of the foot you may soon recover, but a slip of the tongue you may never get over." Benjamin Franklin

Communication is central to the vitality of an open source project. It is one of the key characteristics that separate and distinguish a healthy open source project from the vast clique of abandoned ideas, defeated plans, and failed forks. Healthy projects communicate, and they do so extensively and openly. Yet, each project has its own etiquette conventions and interaction protocols; unfamiliarity with these can result in an unfavourable experience that can be particularly devastating to newcomers and outsiders.

The benefits that open source offers, however, are still proving to be exceptionally compelling. In particular, commercial industry is becoming increasingly aware of the vast potential held within open source communities and the millions of lines of source code written by impassioned developers around the world that improve and maintain those codes for free. Business institutions often get involved in order to make modifications that support their needs and quickly find themselves ill-prepared to be thrust into the realm of open source software development.

Business institutions tend to structure and manage projects very differently from open source projects. Dan Woods wrote about this "collaboration gap" for Forbes, describing how the difference in management styles and communication mechanics often creates a distinct collaboration disconnect. Learning to bridge the differences makes it considerably easier for business institutions to garner the greatest long-term benefits of participating in open source.

A successful open source project thrives on extensive and pervasive communication and on sharing information. Most businesses are not good at sharing information -- at least not for free and rarely without monetary gain. Some organizations avoid sharing as a means to protect their business secrets. Some don't share in order to minimize risk - legal, competitive, or otherwise. Others don't share simply because that takes time and they don't perceive a financial benefit.

Institutions venturing into the realm of open source for the first time often have difficultly figuring out how to communicate effectively, particularly beyond the domain of their marketing departments and while keeping their risk-averse management happy. Many fail to interact effectively due to significant differences in priorities and protocols. So, how does a company share information without giving away business secrets, without taking on additional risk, and while still realizing a financial gain? The key is to find common ground for communication and collaboration.

Delegate Individual Responsibility

Business institutions tend to participate in open source projects differently than individual open source contributors. Understanding how to communicate with an open source community provides the greatest benefits to an organization and helps establish a long-term mutually beneficial relationship with the largest potential gains. The first crucial step along that path is to delegate responsibility down to individual contributors.

Open source communities don't care about the company behind an individual or effort. They care about contributions and the abilities of contributors. Often, great open source communities are meritocracies. The best ideas win because they are great ideas, not because they are from someone important. Corporate reputation holds little credence. In a meritocracy, individuals with a reputation for good ideas are in charge. Companies have to empower and pay their workers to make connections and network. Individuals make contributions, not institutions. Realizing this difference is a big first step.

Go Where they Go

Open source communities have a plethora of resources at their disposal for interaction. While private e-mail communications and face-to-face meetings may be the norm for corporate business, most open source projects operate over chat networks, discussion forums, and other internationally-accessible on-line mediums. When getting involved with a new community, figure out where the existing contributors predominantly interact.

Three of the most common communication mediums that developers use are e-mail mailing lists, on-line discussion forums, and Internet Relay Chat (IRC). Some projects operate exclusively over one medium while others will utilize multiple mediums simultaneously. IRC is particularly interesting as the medium provides group discussions in real-time. Users are often connected to an IRC network 24/7 and communication etiquette can be unfamiliar, strict, and unforgiving to new users. The Freenode IRC network is a particularly common home for many open source projects due to the network's focus on open source software communities.

Know How to Talk

Once you find them, there are still several matters of etiquette that have to be taken into consideration. Failure to follow common etiquette, rules of conduct, and interaction protocols is viewed by many open source developers as an unforgivable offense. Responses can range from helpful guidance to correct misbehaviour to outright permanent bans without warning. Here are some summarized tips for establishing good communication rapport and hopefully avoid some of the more common pitfalls:

• DON'T WRITE IN ALL CAPITAL LETTERS: this is considered SHOUTING. It's considered rude. Don't do it.


• speling n grammr r imprtnt: poor grammar might work for talking to teenagers over text messaging, but most open source developers are pedants for accurate communication. You don't necessarily have to capitalize your words or end every phrase with a period, but using shorthand is usually a big no-no. It's viewed as lazy, distractive, and annoying.


• Don't top-post: one of the most common reply styles in business e-mails will infuriate many open source developers. Instead of replying at the top of a message, reply in-line or at the bottom. Particularly on open source mailing lists, be conscious of how you reply to messages.


• Be concise: and get to the point. Basic context is helpful, but many open source developers consider their time more sacred than yours. If you need help with something, say what you need help with and only the details that are immediately pertinent and relevant. Whether you're developing a source code patch or asking for help, don't mix topics.


• Do your homework: if a quick Google search will answer your question, you are wasting the time of others by asking. Read the README file, read the developer guidelines, read their forum FAQ. If you think your question might be covered somewhere but you're not sure where, then specify what you've read that pertains to the problem at hand. This will prove that you have been doing your homework and will also help them refine their documentation.


• Be polite: the project does not owe you anything. Many open source developers have a tendency to provide very blunt or tort responses, but your tone, particularly as a newcomer, should always remain cordial. Leave cynicism, arrogance, egos, and emoticons at the door.


• Be patient: while you may be paid to talk to them, they are often not paid to talk back to you. Particularly for IRC, responses are often instant but they can come hours or even days later. You are expected to wait patiently and quietly if you are seeking interaction.


• Ask smart questions: see How To Ask Questions The Smart Way for a good overview.

Communicate Early, Communicate Often

It's a rare open source project that enjoys someone showing up, dropping off a patch file, and disappearing. If you're working on a modification that you intend to contribute back to an open source community, you should be communicating as early as possible. You will be seen as an active participant, not just a passing visitor. Discuss your goal, your needs, and how you currently plan to proceed from a technical implementation perspective. Be flexible, prepared to work with others, and willing to adjust your plans. Ideally, you should be communicating continuously while you're working. Daily updates while you are working are encouraged. The more the better.

Be Honest and Earnest

The final note I'd like to leave you with is about the forthrightness of most open source communities. Many open source participants have a highly tuned BS sensor and low-tolerance for masked intentions. Honesty is highly valued and reflects directly back onto the contributor. An individual contributor's merit within a meritocratic community will grow if: i) they are contributing constructively to the project and ii) they are deemed trustworthy through openness and honesty. It should go without saying, but a little common sense honesty can go a long way towards earning respect.

Facilitating Non-Code Contributions

In today's column, Carlo Daffara continues his discussion on non-code contributions:

In a previous column, I mentioned how a substantial amount of contributions in large projects are not provided in the form of code, but in many other forms. Examples include documentation, knowledge (maybe enclosed in mailing list posts), graphics, and so on. Code is actually one of the last, and most complex, form of contribution as it does require substantial skill and knowledge. While it is true that most projects provide a structured form to submit and contribute code, there are very few projects that make it easy to submit other types of contributions.

A good start is to show that you actually want contributions. There are countless open source projects that never mention in their web page or documentation the fact that external participation is welcome. Having a page like “contribute” on your project website is a good start. A perfect example is the Fedora Project page.

In this example, the join page is really a contribute page and is found just after the link on how to obtain the distribution – a very visible and clear position. The page also shows the many different ways someone can contribute: by writing text or documentation, contributing graphical elements, by being an ambassador or representative, and so on. In the single subpage, the complete description is simple and allows latitude to adapt. As an example, in the “People Person” page there is a welcoming text that says “Remember that you have complete freedom to do less, more or different tasks in the many projects and teams. Only your imagination sets the limits.”

A similar approach appears in the Funambol participate page. While simpler, it conveys a similar message: participation is not exclusively about code.

We can provide, based on these examples, a few suggestions to improve your project visibility in this area:

• Explicitly mention the opportunity to participate in your project, and if possible add a participate page to your website.


• Before listing what you want from others, think about what may be considered a contribution, even if it may be small. For example, mentioning the use of your project's software can be considered the smallest, but still a significant, form of contribution. In the case of Funambol, it provides an indirect economic value to the commercial project that is based on the open source code base, as it demonstrates market viability and the fact that there is an established user base.


• List explicitly all the possible contributions, and for each present an example. Instead of simply mentioning “graphic contributions”, list a set of possible tasks, like “a new splash screen”. Try, if possible, to list potential contributions of different sizes, listing the easiest ones at the beginning. This provides an immediate frame of reference for the amount of time or effort that may be necessary for a contribution, and gives even first-time participants the opportunity to work on small activities.


• Whenever possible, provide tools for specific tasks. For example, Bazaar provides a translation tool that helps in creating localized strings. In larger scale projects, creating a sub-project for a specific activity may help in coordination and in reducing duplication of effort.

There is a huge world of potential contributions, and just a little effort is needed to assist potential contributors in materializing those potentials.

Getting The Work Done

Today's columnist is Emma Jane Hogbin from Hick Tech. She writes:

Several weeks ago I decided it was time to delegate some of my work. I needed a set of notes from one of the classes I taught converted into an eBook. I knew that I wanted to be able to edit the material myself and that I wanted everything to be done in an open source tool. "Easy," I thought. "I'll just hire a F/LOSS person to do this for me." It turns out: not so easy after all. I asked my network of people if they knew any graphic designers who did book layout and worked in open source tools. What came back was the sound of crickets. Inconceivable! How could there be no one who matched my criteria?

A colleague of mine told me that he often uses online "freelance" networks to job out some of his tasks. He recommended both Elance and oDesk. My job description was short:

I need someone to do layout work on several short ebooks (~20 pages). Due to their technical nature (HOWTO programming guides) I need to be able to edit the documents easily if mistakes are reported. Even though it's not a layout tool, I would prefer the work to be submitted as OpenOffice.org documents with styles correctly applied (not manually adjusted per heading/paragraph etc). 1. Are these constraints you are able to work within? 2. Approximately how many hours do you think it will take to create and apply a style guide to a short ebook?

The list of applicants was even shorter. On Elance I received three applicants, one of whom asked me, "Do you have MS Word? It has excellent layout capabilities, and I prefer to work with that program." oDesk returned a much longer list of applicants from Asia Pacific. None of these candidates seemed to know what OpenOffice.org was. I had thought that open source software was big in India, Thailand and Malaysia. I ended up hiring a Belgian through Elance with a Masters in Graphic Design who'd never used OpenOffice.org before. She was a delight to work with and caught on quickly. (Look for "anndesign" on Elance.)

While oDesk and Elance both have a lot of open source software tools listed for server-side tasks, they are devoid of people offering desktop publishing skills. Fewer than a dozen providers on Elance have DocBook listed, and only one provider has listed OpenOffice.org. It's possible that there are swaths of people with desktop publishing skills who are looking for work elsewhere, or perhaps they are so busy with work they aren't using sites like Elance or oDesk. Either way, this makes it difficult for me to get my work done.

Even though I have an excellent graphic designer who sends me all source files for business cards and other graphic work, eBooks does not have an easily converted source file. Most graphic designers these days seem to use In Design. While the open source application Inkscape can open Illustrator files, there is no crossover application for book layout. There are perfectly viable open source tools, yet the demand is simply not there for graphic designers to take the plunge. Here's what we need to do:

• If you are someone who works with open source desktop tools, please register your services in one of the online freelance marketplaces. If you already are registered, please let me know where to look for you.


• Ask your graphic designer to return source files in an open format.


• Seek out professionals who work with open source tools. Name specific F/LOSS applications as part of your job posting. My Elance provider saw the software name and downloaded it before replying to the job posting.

We need to show that there is a new demand for skilled labour with experience in open source applications. We've done a good job of getting server-side F/LOSS tools into the language of the server room, now we need to do the same in the front office. It's up to us to ask for the skills and educate our workforce--it will give higher visibility and increase adoption of our applications of choice. There is no easier way to affect change than to simply make it part of our daily routine.

Canada--Social Innovation Nation?

Today's columnist is Stephen Huddart from the J. W. McConnell Family Foundation. He writes:

It seems that everywhere you look these days, people are calling upon Canada to invest more in innovation. Here for example is Preston Manning on the topic and here is former Privy Council head Kevin Lynch. Such commentaries typically focus on the roles of business, government and universities – but either barely mention or completely ignore the community or voluntary sector. For those of us who work and volunteer in this sector, this is a regrettable and all-too-familiar oversight.

Tim Brodhead, President and CEO of the J. W. McConnell Family Foundation, has provided a helpful reminder of this sector’s powerful role in innovation, as well as a comprehensive analysis of the sector’s recent history and future potential. As he notes in the former document, the most recent Speech from the Throne makes a break with the usual pattern of omission, and refers to innovative charities working in concert with business and government to solve persistent social problems. The speech states that:

Every day, the power of innovation is seen at work in communities across this country, as citizens, businesses and charitable groups join forces to tackle local problems.

Too often, however, grassroots efforts are hobbled by red tape. Too often, local solutions are denied access to government assistance because they do not fit the bureaucratic definition of the problem. Too often, the efforts of communities falter not on account of a lack of effort or heart, but because of a lack of expertise to turn good ideas into reality.

• Our Government will take steps to support communities in their efforts to tackle local challenges.
• It will look to innovative charities and forward-thinking private-sector companies to partner on new approaches to many social challenges.

Before we can consider the community sector’s role in catalyzing innovation, we need to look at business model innovation within the sector itself. As Bill Drayton points out in Massive Change, from 1700 onwards business innovation has generated compounded productivity increases of 2 - 3% per year, while the social sector’s tightly regulated operating system of grants and donations has hardly evolved since the 1800’s. To support the passion and entrepreneurial energy that shape bold new ventures, innovative models and methods are essential.

First Steps: Creating Time and Space for Innovation in the Community Sector

Continuous innovation in the community sector has only emerged in the last couple of decades. Within this timeframe, McConnell developed a suite of national programs that tested, adapted and scaled up new approaches over periods extending up to a decade or more. In fields ranging from community economic development to arts in education, breakthrough results came about because a funder was prepared to accompany grantees through cycles of testing, failure and adaptation rather than put them all to sleep in a Procrustean bed. Tides Foundation Canada, established in 2000, introduced shared back office services so that social and environmental innovators could spend more time on their mission-related work and less on operating redundant, resource-intensive administrative structures. The Kahanoff Centre in Calgary and the Centre for Social Innovation (CSI) in Toronto introduced co-location for non-profits so that they could benefit from access to shared services, economies of scale, and convergence innovation – the unexpected results of people and ideas bumping into one another. Today CSI is home to over 100 nonprofits and is linked to centres like the Hubs in Halifax and London, England. A second site is in the works. The model works in smaller centres too - the Creative Space in Barrie operates on similar principles. Counter to this promising trend - and to the government’s stated intentions in the Throne Speech - Industry Canada has just announced that it is ending support for much of its Community Access Program. This noble effort to bridge the digital divide ensured that low income and transient people had access to the net and supported innovations like Homeless Nation.

Next Steps: Building a Culture of Social Innovation

Social Innovation Generation, a partnership between McConnell, MaRS Discovery District in Toronto, the University of Waterloo and the PLAN Institute in Vancouver was designed to enable closer collaboration among institutions with complementary capacities for supporting social change. At the risk of oversimplification, McConnell contributes funding, convening and several communities of changemakers; MaRS adds support for social entrepreneurship and social finance; Waterloo brings intellectual leadership, research capacity and new tools for organizational learning; and PLAN’s work with the disability sector exemplifies how an entire domain can be shifted from ‘problem’ to ‘promise’.

New operating systems for the community sector are about to emerge. One set of strategies is clustered under the heading of social finance – funding and organizational models that support hybrid organizations generating both profits and specific public benefits. Shared reporting platforms are needed to streamline relations between funders and grantees. We need a new marketplace for good ideas in this sector – one that removes some of the barriers to bringing good ideas to the attention of funders, and to scaling up the best ideas. When one funder has done due diligence on a proposal it can often save others the trouble – here's an idea from Philanthropy Australia that might be worth building upon. Other areas in development include tools for measuring social impact, and open software platforms that enable multiple organizations to share data and learning.

To take this work to the next level, we need public, private and philanthropic investments in these areas, plus an accessible, adaptable architecture – an ecology if you will – that supports new players entering the field - locally, regionally and nationally. With social innovation partnerships and hubs in place, and networked, a whole new set of capacities and possibilities emerges.

For the open source community – volunteer developers, teachers, students, entrepreneurs – the needs and opportunities are boundless. In addition to the work involved in connecting the community sector with new, networked means of getting things done, whole new frontiers are opening up: working with open API databases to create new data sets for analyzing and tracking social innovations will generate new knowledge and enable innovation collaboratives to learn and adapt quickly.

When private and public institutions collaborate with the community sector, disruptive innovation can take place, saving scarce resources, improving services and deepening civic engagement. An illustrative example is PLAN’s Tyze program, which enables collaboration between the formal and informal health sectors. This one social innovation, developed in Canada, has garnered attention and support from the Robert Wood Johnson Foundation in the US and is also being piloted in the UK. Imagine what could be accomplished with a pipeline of such ideas, as Mexico is building with its Oportunidades program.

Canada: Social Innovation Nation?

As a uniquely diverse society with a strong community sector (the second largest in the world as a share of the economically active population according to The Canadian Nonprofit and Voluntary Sector in Comparative Perspective; Imagine Canada 2005), we have some natural advantages when it comes to social innovation. Observers who have rightly pointed out that innovation = productivity = social wellbeing have often missed the fact that the community sector provides invaluable social R&D, and that hobbling it with outdated business models is a serious drag on the economy.

The open source software community is part of this picture too, although often overlooked because it isn’t organized into ‘charities’ where things like volunteer hours can be counted. Unleashing the generative possibilities among open source technologies, new social process tools and the community sector ought to be a priority component of our national innovation strategy, and would help Canada to define and occupy an advantageous global niche.

Go Green: Reduce, Reuse, Refactor

Today's columnist is Christopher Sean Morrison from BRL-CAD. Sean writes:

I recently had an epiphany. Go Green. At least, that was what initially came to mind. I wasn't thinking about recycling soda cans, planting trees, preserving rain forests, or reducing my carbon footprint -- however honorable and beneficial those activities may be. I was thinking about open source. Open source needs to Go Green.

Before I lose you on the metaphor, let me rewind back and set the stage a little. A few weeks ago, I found myself doing what I love most, in an intense coding session working on one of my favourite open source projects. I was "in the zone", working in code for hours and hours on end without any distractions. Intense maybe isn't the right word for it, though. Painful. Yes, painful and frustrating. That fits much better. You see, instead of writing something cool and awesome during my insular zone time, I was hunting down a rather elusive bug. No epiphany to be had there.

It was the sort of frustrating grunt work that one loves to hate. I can usually isolate a bug in source code pretty quickly, but this bug was not cooperating at all. Quite rude. If fact, after many hours of hunting across dozens of debugger sessions, recompiles, and testing, I eventually threw in the towel on a direct approach.

Contrary to the vast array of debugging tools and experience at my fingertips, I found myself manually hunting through commit history in a binary-search fashion so that I could at least pin-point the change that caused the bug in hopes that the cause would be evident. After about four hours of hunting, I had finally narrowed it down to within a mere 1000 commits. Add a couple more hours and I'd finally found the exact problematic commit, isolated the bug, and a fix was in place by the end of the day. Still no epiphany.

I originally avoided manually searching history as I knew it would be tedious, boring, time-consuming, and most importantly, I knew that this non-critical bug had been there for a while. Our regression test suite caught the bug the moment it happened and -- while I'm sure there was a perfectly reasonable justification at the time -- it was duly ignored by all developers and it stayed that way for many months.

No epiphany necessary there either. It's obvious in hindsight that the bug shouldn't have been ignored. It would have probably been less costly to fix had it been addressed the moment it was detected during regression testing. Kaner, Bach, and Pettichord write about how bugs are cheaper to fix the earlier they are found in Lessons Learned in Software Testing: A Context-Driven Approach. McConnell strongly reinforces this notion in his book Code Complete. That decision blunder isn't the highlight, though.

A couple days later as I was tidying up the loose ends, finishing bug fix verification, and updating documentation for our release notes, I was flabbergasted by what I found. Not only was the bug already documented, there were notes on the cause, details on why it wasn't immediately handled, and thoughts on a proposed fix, all conveniently offered in plain sight exactly where it was supposed to be. Not only that, the commit log added insult to injury: I was the one that documented it.

You see, this particular open source project is a large, complex software suite with more than a million lines of code, dozens of libraries, and hundreds of tools. There is a lot of documentation. So much so that when some contributors started translating some of our documentation to another language, I was astonished to discover that we had somewhere between half a million and a million words. That's at least a few thousand pages even without pictures! Even still, what is written is considered insufficient and many features are still not documented despite our efforts.

Epiphany realization begins.

I started thinking hard about documentation and software complexity. If I had just overlooked that little piece of developer documentation that was succinct, easily accessible, in the right place, and even written by me, how awful might the situation be for our users that have to wade through a sea of unfamiliar documentation in a myriad of formats and locations. The organization, clarity, and complexity of the documentation is in direct correlation with the software itself. This is a software ecosystem problem.

The ecosystem software developers deal with is a complex world where toxic and eco-friendly practices for managing software share common ground. The structures we erect and fields we sow are impacted by ingrained complexity of features and complexity of implementation which in turn affect the manner in which they are managed. The more complex the environment, the harder they are to make easily navigable by others, the more overhead and infrastructure are required to provide basic services, the more costly they are to maintain.

Applying similar concepts of environmental responsibility, going "green" is about making real and lasting changes to the way software is managed. A few basic guidelines can be applied to pretty much all software projects, including open source, with relatively minimal effort. Eco-friendly developer activities strive to minimize complexity, maximize value, and optimize efficiency. This philosophical conservancy is aimed directly at improving the environment of all open source through Reduce, Reuse, Refactor.

Reduce Complexity

Complexity is acquired in open source projects in many ways but none as harmful (to users) as through the proliferation of options. If there's a request that can be solved with one more checkbox, another menu option, or just one more tool, there's generally a developer willing to implement it. The user gets their feature. Everyone else pays the price.

Source code complexity increases to implement the feature. The complexity of the user interface increases to present the feature. Documentation complexity (if even updated) increases to annotate how it works. All of those increases have implicit long-term maintenance and associated support costs.

In the commercial world, there are often managers, corporate culture, designers, and marketing teams to keep the proliferation of options in check. Apple has consistently demonstrated a strong capacity to produce relatively simple interfaces that expose a relatively minimal subset of options. While most open source thrives on freedom and choice, that does not mean that every option under the sun has to be presented to the user or that usability should be an afterthought. Ubuntu Linux is a great example within open source where usability is a primary focus.

Pay more attention to usability. Your users will thank you. The OpenUsability initiative specifically focuses on improving the usability of open source software by helping pair usability experts and designers with open source software developers. Open source projects need to organize their information, categorize features, and carefully consider the impact of exposing every feature to the user. Get rid of functionality that provides marginal value to users.

Reuse Components

Consolidate and collaborate. Instead of reinventing the wheel and writing things from scratch, spend that extra time trying to make someone else's code work. Most open source developers hate to hear this, thinking they can write what they need from scratch faster than they could integrate someone else's work. The truth of the matter is, though, that it's simply not nearly as much fun to read code as it is to write it yourself.

Reusing components doesn't just refer to other people's code. Reuse your own code and make it modular, well documented, and reusable by others. Joel Spolsky of Fog Creek Software wrote a fantastic article on this very subject entitled Things You Should Never Do, Part I where he writes about not being delusional that code written from scratch is inherently any better than code that already exists.

Even if a component is not directly usable or might take longer to integrate than it would to write from scratch (regardless of that claim generally shown to be a fallacy in the long-term), there is more aggregate value adding through reuse. In other words, you are being socially responsible to the open source environment by helping improve the existing landscape rather than merely adding to it. Collaborate with others.

Refactor Functionality

There are now several excellent books and an abundance of online resources that cater to code refactoring. Kerievsky talks about "bad smells" in his book Refactoring to Patterns where he points out a series of common source code issues that are indicative of potential problems. Martin Fowler and other authors provide a compendium of about 70 different improvements that can be made in Refactoring: Improving the Design of Existing Code. Particularly with regards to code duplication, adhere to the principle of "Don't Repeat Yourself" (also known as "Duplication is Evil"). Hunt and Thomas articulate this and other concepts in their book The Pragmatic Programmer where they characterize how to make code flexible, easy to adapt, and reusable.

From a practical developer perspective, there are a plethora of basic guidelines that will help future development and maintainability. Eliminate duplicate code. Break large complex functions up into smaller simpler functions. Remove classes and structures that don't provide value. Simplify complicated design patterns. Use clear, consistent, and simple naming conventions. For open source projects, this is an optimization-minimization problem. Refactor to improve usability. Refactor to encourage reuse. Refactor to improve maintainability.

Disaster DIY: Adventures in Free and Open Source Software

This week's columnist is Jason Cote from Freeform Solutions. He writes:

Do you like to Do-It-Yourself (DIY)? This is a homage to all the DIY-ers out there. While I was being sucked into the black hole of my latest DIY adventure, I had the marginally comforting epiphany that despite it eating up all the time I had thought I would use to write this article, it also gave me a (cautionary?) tale to share.

First, the background. In October 2006, I set up my first Voice over Internet Protocol (VoIP) phone system using Asterisk. It is amazing what you can do with open source software. In this case, a truly ancient machine (circa 1999) had been pressed into service once more, after a life of file and web server drudgery. This time, the exciting horizon of VoIP beckoned. Maybe the hardware liked being on the cutting edge, since this little machine kept ticking over the years since then, through a failed power supply and a couple of failed hard drives.

My memories of the many frustrating hours spent learning how to put it all together have long since been romanticized, thanks to the time that’s passed since then. I do remember that I had wanted to set it up for some time, and I certainly remember discovering that I needed to know about a great many more things than I had originally anticipated. Nonetheless, eventually, I installed the necessary software and tucked the machine under my desk and tried to forget about it.

Cut to the present day. This week, the power supply failed again, or so I thought. I replaced it with another spare; the motherboard lit up, but the power supply would still not power up. I pulled what I could off the motherboard, and still no joy. No problem, I thought, this motherboard has been running 24/7 for a decade – I'll look at it later. In the meantime, I'll put the drives in another, newer, spare computer, and get the phone system back online.

If this were a movie, you would hear the spooky music right about now.

With the drives in another computer, Linux refused to initialize the storage. I was beginning to sense the black hole way in the distance. Hardware drivers are still the final frontier in open source software. There could be a firmware or other update required. Or, I may have missed changing some obscure system setting. Decision time: continue fussing with the old hardware, or spend my time installing a completely new system?

The old hardware never really stood a chance in this reckoning. For a long time, I have been wanting to install a new phone system, as a virtual machine on hardware located in a data centre. Now, with the old phone system sitting in pieces all around me, it was all too easy to fully commit to this new DIY adventure. I was firmly in the grip of the black hole.

I did not really want to spend much time discovering, evaluating, and comparing the options all over again, but so much has changed in the VoIP landscape over the last three-plus years. I needed to pick something, now. But so many choices. How should I choose? Should I follow the same direction as my original approach, or try something new? Should I support a purely community-driven effort, or one supported by commercial interests? Should I stand my ground on what license was being used? Should I pick something that looked pretty, or something that sounded well engineered?

One of the hardest things in using open source software effectively is knowing when to stop evaluating. If you dive into several projects and look at all these factors, you can be simply spoiled for choice. You’ve got to pick something, and go for it.

I remembered that clock timing issues had been a real problem when running in a virtual server the last time, so I looked for Asterisk-based distributions that seemed to have their virtual house in order.

I like the real or perceived performance improvements provided by paravirtualization over full virtualization, and this preference limits my options. I looked at one distribution, and it was clear they were not supporting paravirtualization by default. I looked at another distribution, which had documentation explaining how it could be paravirtualized; I tried it, but it did not work as advertised. If their website and documentation had been more polished, I would have tried harder. Instead, I found another distribution that claimed to make virtualizing fast and easy.

I was beginning to orbit the event horizon with alarming speed, so I committed.

Let me be clear in saying that this distribution did not work as advertised either. I was quite disappointed, since, other than new learning, my pursuit of the ready-to-run distributions left me empty handed. They did not deliver the value they promised: it was not faster, and it was not easier, unless you wanted to run it on a dedicated machine.

So, having gone through three explorations already – the original failed hardware, the inability of new hardware to boot the old drives, and attempts at virtualizing ready-to-run Asterisk distributions – I turned to the core open source software itself: Asterisk.

In the end, it only took a few manual tweaks to various Asterisk configuration files, and the use of the FreePBX configuration GUI. I quickly and easily created a VoIP telephone system, with all the trimmings – system recordings, a digital receptionist, inbound and outbound routes, extensions, etc. – in only a few hours. By just rolling up my sleeves and diving in with the core open source software I needed, eventually I made it through the black hole and emerged in a whole new universe of working VoIP goodness.

For this, I am extremely grateful. My sincerest thanks to all of us in the free and open source software community, for making things for DIY-ers to do. This is how my tale turned out. Others might end up in completely different places when starting at the same point. That’s a core strength of open source software: it gives us all choices, and the freedom to pursue them in any direction (including around in circles).

March Issue on Mobile Published

The editorial theme for the March issue of the OSBR is Mobile. The guest editors are François Lefebvre from Communications Research Centre, Canada and Thomas Kunz from Carleton University, Ottawa. This month's authors include:

Andreas Constantinou is the Research Director at VisionMobile. His article discusses the importance of governance models to understand the dynamics of an open source product, constrasting it to the better understood role of licences. Using the mobile industry as an example, he demonstrates how governance models can be used by open source sponsors to control the development of open source products, and argues for more education and clarity on governance models.

Jason Kridner is the open platforms principal architect at Texas Instruments Incorporated. His article discusses the challenges and successes in establishing a vibrant ecosystem around the BeagleBoard, a low-cost, fan-less single-board computer. The efforts within this community have allowed the BeagleBoard to become a versatile and powerful open embedded device.

David Burgess of the OpenBTS Project discusses the project's experiences, which will probably become the first case of a free software GSM basestation in a public cellular network. The article focuses on the challenges of the project, as well as the advantages of having followed the open source route.

François Lefebvre leads the Mobile Multimedia Broadcasting team at Communications Research Centre, Canada. His article surveys CRC’s attempt to increase collaboration and innovation in the field of mobile broadcasting by developing and offering complete end-to-end free and open source software toolsets.

Carl B. Dietrich, Jeffrey H. Reed, Stephen H. Edwards and Frank E. Kragh discuss OSSIE, a university-based open source Software Defined Radio project at Virginia Tech. OSSIE software has proven useful for rapid prototyping by industry as well as for published research and education of hundreds of graduate and undergraduate students. In addition to examples of OSSIE’s successes, the project’s challenges and approaches to mitigating and overcoming them are described.

Hal Steger, Vice President of Marketing at Funambol, inc., introduces the cloud computing paradigm as a way to deliver mobile applications and data. His article discusses trends that are driving the adoption of the mobile cloud, important components of mobile cloud infrastructure, and the role of open source.

Bradley M. Kuhn is the Policy Analyst and Technology Director at the Software Freedom Law Center. He briefly reviews the history of free software in the mobile device space, focusing on both software and hardware. A review of the available alternatives to-date leads him to conclude that users, while able to access open code bases from major companies, are at the mercy of these companies. For a number of reasons, true software freedom on mobile devices is, as yet, an elusive goal.

To "Open Source" or Not to "Open Source"

Today's column is by Julian Egelstaff of Freeform Solutions. Julian writes:

"Let me assure you that whatever problems the Mozilla project is having are not because open source doesn't work. Open source does work, but it is most definitely not a panacea. If there's a cautionary tale here, it is that you can't take a dying project, sprinkle it with the magic pixie dust of 'open source', and have everything magically work out. Software is hard. The issues aren't that simple." Jamie Zawinski, co-founder of the Mozilla project, at the time of his resignation in 1999

An odd question landed in my inbox recently. A development team was looking for advice about open source licenses. Specifically, they wanted to find a license that would:

• require the consent of the original developers before distributing the code, except among a small group of related organizations


• require people to notify the original developers if they use the code and if they make any changes to the code


• disallow the selling of software based on the code

Doesn't sound very open does it? That was my basic response...this team doesn't want to do open source as far as I can tell. But the idea of open source is out there, sharing code is a hot topic, and these guys did want to share code, just not very widely and only under certain circumstances.

I don't think they're alone. A lot of people feel very possessive of their code. A lot of organizations feel very protective of their investment in intellectual property. For some, sharing of any kind is out of the question. For others, it's an interesting idea, but they don't quite "get it" and they're not sure how it might apply to them.

My advice would be to follow the value. Where is it coming from? If you can answer that question, you'll know if open source is for you.

First of all, remember what open source is...at the end of the day, it's just a way of developing software. Like Jamie Zawinski said when he left the Mozilla project, open source is not magic. But it can have a powerful effect, when its practitioners come together and persevere. Mozilla may have had failures 11 years ago, but these days it's home to one of the most successful projects in the world, Firefox.

Open source is a way of developing software, that tries to leverage contributions from the entire community of users. In practice, only a small number of users contribute to the actual programming, but any user at all can contribute to bug reporting and testing, documentation, and even planning features for future releases.

To guarantee that collaboration, open source licenses enforce certain obligations on the users of the software, most notably that they must provide the source code every time they distribute the software to someone else. That way, no one is left "out of the loop", so to speak. Everyone is on an even playing field when it comes to the use and development of the software. At least theoretically.

The fact is, just having the source code is never enough. Even armed with the source code, no one is going to out-mozilla the Mozilla Foundation. Lesser projects may get forked from time to time, but who in their right mind could ever fork Linux?

Open source projects exert a powerful control over their own direction and destiny through all kinds of other means, besides the licensing agreement. The right to the source code may be the under pinning of open source, but just like freedom of the press in a democracy, it's the actions and ideas of the people who use that right which truly guarantee the freedoms that the right is there to protect. The community is as important to open source projects as the code is.

The right to the source code, and the will to pick it up and use it: those are the two mechanisms that drive open source forward. So what does that have to do with value? Well, if you're in a classic software development business, along the lines of Microsoft, then you're betting that the value in your business comes directly from your ability to develop software that is better than anyone else's, or at least more widely desired, and to essentially limit access to it and charge for every copy. Creating value in that kind of a situation means you've got to maintain a big marketing and sales team, and all kinds of things that don't have much to do with the act of software development, just to protect (or create?) the value that is ostensibly derived from your software.

The problem with that kind of value proposition, is that most people assume that's the value proposition all software has. Nothing could be further from the truth. I have seen many organizations instinctively hoard software, because they think software in general has intrinsic value, even though they have no marketing or sales organization whatsoever. In fact, the software is contributing nothing to their bottom line at all, but they still won't release it, because it's "theirs".

What if the value comes from something else? What if the value doesn't come from the software itself, but instead comes from the domain expertise of your organization or your developers? What if the value comes from the way in which you know how to use the software? There are all kinds of sources of value that surround software, that don't come directly from it. If that knowledge and those activities are the true source of value in your case, then releasing software as open source can make a ton of sense.

I think people need to ask themselves, "what is the worst thing that could happen?". This often puts everything in perspective. If your software is released into the wild, will someone run away with it and somehow harm your organization? What if they had to share all modifications they made to the software? Chances are, you will be at the centre of the community that grows up around the software.

And if the value is in all those things that surround the software, then being in the middle of that space gives you other benefits and opportunities as people turn to you for expertise and support and leadership. By embracing an open source model, organizations can create value from software that might otherwise be contributing nothing to the organization.

So what did that development team do, that was thinking of open source but didn't sound like they really wanted it? Predictably, they didn't open source their software. But just because they lost an opportunity doesn't mean you can't find one! Look around at the software you are developing, ask yourself how it creates value for your organization if you keep all that code to yourself. In many cases, I bet you'll see that the real opportunities come from the community of users and contributors you haven't met yet.