Oh, sure. You may know how to set up a GitHub account and get started, but such mechanics are actually the easy part of open source. The hard part is making anyone care enough to use or contribute to your project.

Here are some principles to guide you in building and releasing code that others will care about.

First, The Basics

You may choose to open source code for a variety of reasons. Perhaps you're looking to engage a community to help write your code. Perhaps, like Known, you see "open source distribution ... as a multiplier for the small teams of developers writing the code in-house."

Regardless of the reason, this isn't about you. Not really. For open source to succeed, much of the planning has to be about those who will use the software. As I wrote in 2005, if you "want lots of people to contribute (bug fixes, extensions, etc.," then you need to "write good documentation, use an accessible programming language ... [and] have a modular framework."

Oh, and you also need to be writing software that people care about.

Think about the technology you depend on every day: operating systems, web application frameworks, databases, and so on. These are far more likely to generate outside interest and contributions than a niche technology for a particular industry like aviation. The broader the application of the technology, the more likely you are to find willing contributors and/or users.

In summary, any successful open-source project needs these things:

1. Optimal market timing (solving a real need in the market);

2. A strong, inclusive team of developers and non-developers;

3. An architecture of participation (more on that below);

4. Modular code to make it easier for new contributors to find a discrete chunk of the program to work on, rather than forcing them to scale an Everest of monolithic code;

5. Code that is broadly applicable (or a way to reach the narrower population more niche-y code appeals to);

7. A permissive license—I personally prefer Apache-style licensing as it introduces the lowest barriers to developer adoption, but many successful projects (like Linux and MySQL) have used GPL licensing to great effect.

Of the items above, it's sometimes hardest for projects to actively invite participation. That's usually because this is less about code and more about people.

"Open" Is More Than A License

One of the best things I've read in years on this subject comes from Vitorio Miliano (@vitor_io), a user experience and interaction designer from Austin, Texas. Miliano points out that anyone who doesn't already work on your project is a "layperson," in the sense that no matter their level of technical competence, they know little about your code.

So your job, he argues, is to make it easy to get involved in contributing to your code base. While he focuses on how to involve non-programmers in open-source projects, he identifies a few things project leads need to do to effectively involve anyone—technical or non-technical—in open source:

1. a way to understand the value of your project

2. a way to understand the value they could provide to the project

3. a way to understand the value they could receive from contributing to the project

4. a way to understand the contribution process, end-to-end

5. a contribution mechanism suitable for their existing workflows

Too often, project leads want to focus on the fifth step without providing an easy path to understand items 1 through 4. "How" to contribute doesn't matter very much if would-be contributors don't appreciate the "why."

On that note, it's critical, Miliano writes, to establish the value of the project with a "jargon-free description" so as to "demonstrate your accessibility and inclusiveness by writing your descriptions to be useful to everyone at all times." This has the added benefit, he avers, of signaling that documentation and other code-related content will be similarly clear.

On the second item, programmers and non-programmers alike need to be able to see exactly what you'd like from them, and then they need to be recognized for their contributions. Sometimes, as MongoDB solution architect Henrik Ingo told me, "A smart person [may] come[] by with great code, but project members fail to understand it." That's not a terrible problem if the "in" group acknowledges the contribution and reaches out to understand.

But that doesn't always happen.

Do You Really Want To Lead An Open Source Project?

Too many open-source project leads advertise inclusiveness but then are anything but inclusive. If you don't want people contributing code, don't pretend to be open source.

Yes, this is sometimes a function of newbie fatigue. As one developer wrote recently on HackerNews,

Small projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: if I where[sic] to help them out, I'd spend my limited available time on handholding people who apparently managed to get ms degrees in cs without being able to code instead of doing what I enjoy. So I ignore them.

While that may be a good way to maintain sanity, the attitude doesn't bode well for a project if it's widely shared.

And if you really couldn't care less about non-programmers contributing design input, or documentation, or whatever, then make that clear. Again, if this is the case, you really shouldn't be an open-source project.

Of course, the perception of exclusion is not always reality. As ActiveState vice president Bernard Golden told me over IM, "many would-be developers are intimidated by the perception of an existing 'in-crowd' dev group, even though it may not really be true."

Still, the more open source projects invest in making it easy to understand why developers should contribute, and make it inviting to do so, the how largely takes care of itself.

Over the past decade, I've watched open source become standard operating procedure within large and small enterprises. Once confined to software, open source is at the heart of a hardware revolution led by Facebook, not to mention bleeding over into other industries. There's even an open source ski boot now.

But broad adoption doesn't necessarily mean open-source code is the solution to all of the world's problems, much less the failing HealthCare.gov website. Despite petitions and PR to the contrary, it's not actually clear that open source will solve what ails Healthcare.gov.

Déjà Open Source?

We’re making our source code freely available on GitHub. All of our educational content about the Health Insurance Marketplace is available in machine-readable formats so that innovators, entrepreneurs, and partners can turn it into new products and services.

The problem is that this isn't the code that needed most to be open. The culprit behind the system failures was the meatier, more difficult back-end software, which was written by 50-plus contractors behind closed doors and released in the old-school, legacy software fashion, as The Verge reports.

Needless to say, it was the back-end code that crapped out when put under a heavy load.

This is inanity at its best (or worst). As Cloudera's Mike Olson has pointed out, all essential infrastructure technology has been moving to open source for some time, a trend that is likely to continue.

A Problem Of Process, Not Code

It turns out that infrastructure code benefits from having many different people involved so long as their efforts are coordinated in the open. As critics like Paul Ford highlight, HealthCare.gov failed not so much because of its code, but rather because of how it was assembled and rolled out: in secret.

Companies such as Google, Amazon.com, Twitter and Facebook all ... deploy lots of small teams that are expected to ship new features and fixes all the time—sometimes daily. Like anything that involves human beings, shipping code can devolve into squabbling, missed deadlines, and flawed releases. The programming community’s key realization is that the solution to these problems is to create more transparency, not less: code reviews, tons of “unit tests” to automatically find flaws, scheduled stand-up meetings, and the constant pushing of new code into the open, where it’s used by real people.

Again, the problem isn't code. Not really. The problem is process. This needn't be an overtly open source process, but we've yet to find an equally efficient way of code collaboration between disparate developers.

Anarchy In The UK?

Just ask the UK's director of digital, Mike Bracken. As he tells NPR, a range of UK government websites were beset by many of the same problems that plague HealthCare.gov. As Bracken alludes, the UK government's IT team was "getting too bogged down in long-term multiyear procurements" and "were trying to predict the future in a digital world that's changing rapidly."

Looking at the Healthcare.gov debacle, Bracken faults its cost and its methdology ("large-scale IT enterprise technology, no real user testing, no real focus on end users, all done behind a black box, and not in an agile way but in a big waterfall way, which is a software methodology").

The solution when Bracken and team rolled out Gov.UK? Lots of open-source software, but more importantly, a much more open and agile development process.

And not just any open-source software. Just because code is open doesn't mean a) that it's any good or b) that it contributes to agile development. Whether by license (Apache-style licensing tends to be more flexible than GPL-style licensing) or by code (technologies like Hadoop enable a flexible data infrastructure to allow rapid iterations on the rest of the system), care must be taken to ensure open source equates to open process.

More Than Just Open Vs. Closed

Head over to Slashdot and you'll find no shortage of views that open source is both salvation and stupidity when it comes to HealthCare.gov. This is appropriate, given that it's neither. Or both.

In general, open-source code will be better for projects like this because it involves open source process. But even where both open-source code and open-source process are involved, choosing the right code and right process isn't as easy as just blindly saying "open source." Open source is not a monolithic thing, but rather a composite of many different ways of thinking about open development.

Update (9:27 am PST on November 5, 2013): An earlier version of this post inadvertently indicated that the UK's initial roll-out of Gov.UK was fraught with errors. The problems were actually experienced with earlier versions of other UK government website's, leading to an improved process for Gov.UK. I apologize for the error. (Matt)

The younger generation of developers increasingly eschews formal licensing requirements for their GitHub projects, a trend Redmonk analyst James Governor calls "post open source software." While some will celebrate a full 77% of GitHub projects going commando on licensing, new research from Black Duck Software suggests that this license-free approach comes with as much as $59 billion in hidden costs.

Developers Just Wanna Have Fun

For years the software industry has shifted from copyleft licenses like the GNU General Public License (GPL) to more permissive MIT and Apache Software Foundation-style licensing. The trend has become so pronounced that some question whether the GPL should even be taken seriously, particularly when applied to business. OpenGamma CEO Kirk Wylie, for example, heckles the free software set, arguing that the industry has moved on, with "top VCs [today] view[ing the] GPL as a worst case in all worlds: ideological founders or an unclear business model."

But it's not just the GPL which is seeing a decline.

As new research from Black Duck Software shows, today's developers aren't just moving away from the GPL. They're moving away from open-source licensing altogether. Analyzing over one million projects on GitHub and other code repositories, Black Duck Software found that while 40% of open-source projects industry-wide carry no declared license, 77% of projects on GitHub have no declared license, open source or otherwise.

This is a much different landscape than that found on repositories such as Google Code or SourceForge, where licenses must be selected and used for hosted projects.

The Hidden Costs Of Licensing Freedom

Before you start celebrating the apparent defeat of The (Open Source) Man, consider that of these "license-free" projects a full 42% do come with strings attached in the form of embedded licenses. That is, such projects may incorporate other open-source projects with licenses and associated duties attached for the downstream developer.

As Black Duck found, many enterprises are shying away from projects without a declared license in order to minimize legal risk. Given that Gartner estimates enterprise end-user software spend at $342 billion in 2012, the cost of putting 400,000 open-source projects out-of-bounds for enterprises amounts to $59 billion in lost software savings.

As Black Duck's director of developer marketing, Dave Gruber, pointed out to me (and Black Duck Software highlights in an infographic), it is estimated that 30% of software running in today’s enterprises is open source, saving companies an estimated $146B industry-wide. With 40% of today’s open source projects carrying no declared license, and the majority of organizations unwilling to use projects without a declared license, upwards of $59B (40% of $146B) of potential-use open source software is going untapped.

While this number is subject to debate, given that much of the unlicensed software in question might not be any good and hence wouldn't be used whatever its license, the principle remains: no license will lead to less adoption which leads to more would-be adopters reinventing code they could otherwise use.

True, this isn't the project developer's concern. But it's also true that all else being equal, developers want their code to be used.

Some enterprises will perform due diligence on these hidden embedded licenses and use the unlicensed software anyway. Others will use the software and pray it will work out. But perhaps most will simply avoid these apparently "license-free" projects, foregoing potential pitfalls and benefits.

Whether that cost is measured in billions of dollars of productivity lost or simply throttled adoption for a promising project, it's significant and something GitHub could easily rectify by encouraging or requiring a license.

Monty Widenius, co-founder of MySQL and founder of MariaDB, just came to a surprise revelation: most people use open source for free. What's so surprising, however, is not this fact, but the idea that Widenius wouldn't have learned this 13 years ago when he first released MySQL under the GNU General Public License (GPL) and his company's revenues dropped 80%. The lesson here, however, isn't that there's no money in open-source software, but rather that some strategies for monetizing open source are effective, while others are not.

Monty Got A Raw Deal

For anyone that has been around open source for the past 10 years, hearing Widenius complain about open source free riders is irony at its finest. Widenius, after all, was a technical mastermind at MySQL, and was generally more concerned with MySQL's development community than making money, fighting efforts to monetize the otherwise free database.

Not that this is a bad thing. At any open-source company, developers are the lifeblood of the project and particular care must be taken to cater to their interests and needs. Widenius filled that role admirably.

But Widenius also made it harder to cover the real costs of open-source development, and continues to do so. Recently Widenius attacked Oracle for "suffocating" MySQL through proprietary enterprise extensions, among other things. This may be true, in part, but it's also true that Oracle has 400-plus engineers working on MySQL, and somehow their work needs to be paid for.

In an interview with ZDNet, Widenius (mis)remembers the halcyon of people happily paying for open-source software, and suggests that "Now the problem is that you have companies that are heavily using open source but refuse to pay anything back because they don't have to." This has, of course, always been the case, and yet it hasn't stopped open source from booming, both as a community development and corporate revenue perspective.

Monty's Solution: "Business Source"

Still, Widenius pines for a business model that will help feed development while generating a profit. His strategy, called "business source," effectively amounts to dumping open source entirely, but only for a few years:

[Business source] is a commercial licence that is time-based and which will become open source after a given time, usually three years. But you can get access to all the source. You can use it in any way but the source has a comment that says you can use it freely except in these circumstances when you have to pay.

In other words, it's not open source. It doesn't fit the parameters of the canonical Open Source Definition. That's not necessarily a bad thing, but let's call a spade a spade. Business source is simply proprietary software released under a Microsoft-esque shared source license that magically becomes fully open source after a period of time.

Surely this must rankle the free software-loving Widenius, but he comes to terms with it by espousing the exact same rationale used by those that advocate Open Core or similar strategies for open source:

You're forcing a small part of your user base to pay for the restrictions, which can be if you're making money from [the software], if you have more than 100 employees, or you're a big company or something like that. So you're forcing one portion of your users to pay.

Exactly. But this is the same as the various strategies MySQL tried, which Widenius fought.

It's Not About The License

Jim Jagielski, president and co-founder of the Apache Software Foundation, suggests that "if your open source project isn't successful with FOSS licensing, it's not the license's fault." Rather, it's a matter of trying to charge for the wrong things:

To wit, Facebook, Google, Amazon and others make billions of dollars selling services around open-source infrastructure, while Red Hat mints over a billion dollars annually selling a certified, binary distribution of community-developed Linux. There is plenty of money in and around open-source software. The open-source license doesn't prevent this. It enables this.

Widenius is a smart person. He'll figure it out. It's only surprising that his experience at MySQL didn't already teach him this lesson.

For years, the software industry has been trending away from so-called 'copyleft' licenses like the GNU General Public License (GPL) and toward permissive, Apache-style licensing. Given the rising importance of developers, this isn't surprising: developers just want to get work done without being bogged down by license requirements. It's perhaps not surprising, therefore, that permissive Apache licensing may simply be a way station on the road to no licensing at all.

That's what GitHub seems to be telling us, anyway.

A Trend Toward Extreme Permissiveness

Early in the life of free and open-source software, copyleft licensing reigned supreme. But for years, permissive licenses like BSD and MIT have been climbing, as Redmonk analyst Donnie Berkholz nicely pictures:

Not content to stop there, however, we seem to be entering a new phase: the no-license model. As free-software advocate Glyn Moody notes, "the logical conclusion of the move to more 'permissive' licences [is] one that permits everything."

While Moody talks about public domain software, the GitHub generation seems to be less fussy about legal mechanics.

The GitHub License Black Hole

As Aaron Williamson, senior staff counsel with the Software Freedom Law Center, presented at this year's Linux Collaboration Summit, the vast majority of projects on GitHub don't appear to carry any license terms at all. (The Register's Neil McAllister offers a great summary.) GitHub has become the gathering point for modern open-source development, so it's hugely significant that a mere 14.9% (219,326) of the 1,692,135 code repositories Williamson scanned had a file in their top-level directories that specified a license.

In other words, the vast majority of code on GitHub isn't necessarily open source. Or proprietary software. Or, well, anything. It's just code.

Redmonk analyst James Governor nailed this trend in 2012, arguing that "younger devs today are about POSS - Post open source software." For such developers, Governor holds, licensing and governance are an afterthought: the code is all. Both Gartner and Forrester find that open source is booming precisely because developers want flexibility.

Less licensing = more flexibility.

Is Licensing Necessary?

Not that this approach is unproblematic. Outercurve Foundation board member Stephen Walli posits that such "promiscuous" sharing without governance and licensing will lead to "software transmitted diseases." But it's unclear that the GitHub generation cares. Maybe they will. Maybe they'll wake up and smell the need for licensing.

Or maybe the project/company they create will attract the interest of a would-be buyer, and suddenly source code hygeine will matter. A lot. As a Black Duck study shows, open-source compliance is becoming an increasingly common question in mergers and acquisitions:

But all is not lost. Berkholz analyzed a wide array of projects to determine the interplay between project size and licensing. As he summarizes, "as projects grow, they tend to sort out any licensing issues, likely because they get corporate users, professional developers, etc."

License rebels, in other words, tend to become less rebellious as their projects mature.

Ultimately, then, we almost certainly don't face an industry meltdown stemming from uncertain code provenance. Instead, we have a highly permissive license culture that helps to foster the development of code in the early phases of open-source development, which graduates to Apache-style licensing as projects catch on. Lawyers can rest easy.