OSCON's 20th anniversary and more

The O'Reilly Open Source Conference (OSCON) returned to Portland, Oregon this July for the 20th convocation of this venerable gathering. While some of the program focused on retrospectives, there were also talks and tutorials on multiple technical topics and open-source community management. To give you a feel for the whole conference, we will explore it in a two-part article. This installment will cover a retrospective of open source and some presentations on releasing projects as open source at your organization. A second article will include a few of the technical topics at the conference.

20 Years of open source

OSCON launched in 1999, less than a year after the founding of the Open Source Initiative (OSI) and the drafting of the Open Source Definition. The first conference was a tiny gathering in Monterey, California; it was held side-by-side with the Third Perl Conference and included the board of the young OSI. Ever since, the histories of OSCON and the OSI have been intertwined, including OSI board meetings at most OSCONs.

Accordingly, the OSI ran a "20 Years of Open Source" day, covering much of the last two decades of changes. This included histories of Debian, Red Hat, Mozilla, FreeBSD, and other parts of our ecosystem. This retrospective continued in the "Open Source Past, Present and Future" track in the main program, with talks on how the roles of maintainers have changed, past heroes of open source, and managing projects. One thing that might have startled the attendees of OSCON 1999 was the emphasis on corporate and commercial open source.

One of the more interesting retrospective talks was by Deb Bryant on the history of open source in Oregon, since she was personally there for a lot of it. OSCON itself moved from California to Portland in 2003; 13 of the 20 events have been at the Oregon Convention Center. Bryant attributes Oregon's early adoption of open-source software to its history as a "pioneer state" and its high proportion of small businesses.

Bryant shared a brochure with the audience circulated in 2004 by the city of Beaverton, Oregon, announcing a $1.2 million project to attract open-source business. This campaign enticed the Intel Open Source Technology Center and the IBM Linux Technology Center to start operating there and for the Linux non-profit Open Source Development Labs to relocate there. It also attracted early open-source luminaries to move to the Portland area, including Linus Torvalds, Dirk Hohndel, Greg Stein, and Larry Wall.

This success encouraged the Oregon state legislature to vote on the first bill in the US mandating consideration of open-source software for state procurement. At the time, Bryant was the assistant CIO for Oregon and had to straighten out the mess created by the bill. Particularly, it was written poorly and required the state to define what open source was, which is how Bryant came to be involved with the OSI. Ultimately, the bill failed to pass in the state senate, partly because of the difficulty in explaining open source to legislators who didn't even own computers, she said.

"One advocate tried to explain open source as picking mixed fruit from an orchard", she recalled. "To which an elderly legislator remarked, 'If you pick out of my orchard, you're getting a backside full of buckshot!'"

While the state failed to mandate open source, several agencies did adopt Linux. In 2009, Portland became the first city with a municipal open-source and open-data policy. Bryant also listed off some of the many open-source and open-culture projects started in Oregon, including the Personal Telco Project, the Government Open Source Conference (GOSCON), the Drupal Association, and DemocracyLab.

Later in her career, Bryant managed the Open Source Lab (OSL) at Oregon State University (OSU). This institution was created in 2004 as a place for students to work with and learn open-source tools and system administration skills. Since OSU had a fiber optic internet connection at a time when only universities had them, it hosted kernel.org, Firefox, and other high-traffic projects. More amusingly, Alex Polvi and some other OSU students created a Firefox crop circle in an Oregon field to celebrate the millionth download of Firefox.

Today, the Portland area is home to offices for Intel, IBM, VMware, Google, Puppet, Urban Airship, New Relic, and many other companies that are heavily involved in various open-source projects. With the return of OSCON and all of the many projects and companies active in the city, open source in Portland seems likely to continue to grow.

Community and project management

Another quarter of OSCON was devoted to community management topics. This started with Jono Bacon's Community Leadership Summit the weekend before OSCON and continued with talks in the main program. Many of these talks are practical instructions on how to promote and manage open-source software in a corporate environment, like VM Brasseur's "How to open source an internal project". This talk was given as a kind of preview of Forge Your Future with Open Source, Brasseur's upcoming book on contributing to open-source projects.

Brasseur's core piece of advice to organizations looking to release a software project as open source is to "identify your goals for the project". Companies need to know why they are opening up a project before deciding anything else. It's completely acceptable to want something in return for giving away your software, she said, since it will end up costing you significant time and money to do it.

"You know what I like as much as free software?", she asked. "Solvent companies."

Your return from releasing a project as open source is unlikely to be monetary, but there are other things you can get in return, such as good publicity, competitive advantage, or better hiring prospects. Whatever your reason is, the external community should expect to benefit as well. Open source isn't altruism, it's cooperation, she said.

Once your organization has a goal, figuring out the answers to other questions becomes a lot easier. These include which audiences to approach, which metrics to track, and how to determine if your new community is succeeding.

After you've decide to open a project, there is a lot of "pre-release hygiene" you need to do, including scrubbing the code of credentials, trademark mentions, and profane or rude comments. You'll also need to audit your code for compliance with any licensed content your team has included or linked, whether open source or proprietary. The OSI's ClearlyDefined website can help with this.

You'll need to decide if you need to have a Contributor License Agreement (CLA) or a Developer Certificate of Origin (DCO) for new contributors to sign. You'll want to create a "contributors" file, as well as style-sheets for your code and your documentation to avoid arguments over tabs versus spaces on your first outside contribution. All projects will also need a Code of Conduct (CoC), she said. The one at the Contributor Covenant site is good enough for most projects.

Choosing a license should be the last thing you do, then, instead of the first thing you argue about. For many projects, their licenses are determined by their dependencies. For example, a project that depends on GPL-licensed libraries will probably be GPL-licensed as well. Brasseur recommended GPLv3 for most projects, but cautioned that "there is no one true license". Then you need to ensure that every code file in the project has a license header. She suggested adding a test for that to your continuous-integration/continuous-delivery (CI/CD) system or code linter.

Brasseur finished with instructions on building community, emphasizing above all patience and two-way communication. "Your community needs to feel like stakeholders, not like a free labor force", she warned.

Speaking of stakeholders, Red Hat community team manager Stormy Peters led an interactive exercise for project managers later in the program called "Do You Know Who Your Stakeholders Are?". By "stakeholders", Peters means people who care enough to help the project and would care if it changed or went away. Identifying these people is critical at every stage of managing an open-source project, or an effort to release a piece of software as open source.

There are multiple different kinds of stakeholders for any software project. While companies and other projects that depend on your software or resell it are the obvious ones, they are hardly the only ones. Other types include internal users and other departments, other corporate sponsors, contributors, and even users. If you hold conferences or events, a look at who attends these and who sponsors them can be a good way to identify them. Stakeholders aren't just people and organizations that you have to avoid upsetting; they are also your primary advocates and contributors. Peters recalled an occasion of receiving a full walk-through of a One Laptop Per Child (OLPC) device from a woman who was simply an enthusiastic user.

When you are assessing the health or success of an open-source project, the evaluation that matters is how the stakeholders think the project is doing, not what others think. This is why she recommends doing a regular review of the project with them, either in a large meeting or in one-on-one interviews. These are also instrumental in setting project goals.

Next for OSCON 2018

Of course, OSCON isn't just a community management conference, or even primarily so. There were many technical sessions, tutorials, and keynotes over the four days, a few of which we will present in the next article. Stay tuned for message brokers, container security, and some new technology from IBM.

[Josh Berkus is an employee of Red Hat.]

Index entries for this article
GuestArticles	Berkus, Josh
Conference	OSCON/2018

---

to post comments