# Can open-source be more open?

I have always been enamored by the free exchange of ideas. My first love was the World-Wide Web of the 1990's, then I enjoyed CNET and the freeware scene, and I have had a long, committed relationship to free and open-source software.

But my relationship to free and open-source software was truly like a long-term human relationship. It has and still does require learning, patience, and compromise to appreciate the many software projects that are now part of my daily life.

Should it be that way for the next generation of producers and consumers of free and open-source software? I hope not! There should be a better, easier way.

These communities believe are open and free because they believe in accessibility. How do we make using and consuming that software accessible for developers, no matter how novice?

# Why developers first?

Free and open-source software needs a diverse community of contributors from many backgrounds. But first things first: developers need to write code and make that software real. In almost all cases, a software's developer is its first user. (The Free Software Movement famously [started with one person who very frustrated he could not fix examine and recommend fixes to the printer manufacturer to make their laser printer better](https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt).) Developers are also users! Like-minded developers, with a similar itch to scratch, follow suit. Community coordinators, translators, artists, and users without a development background come much later.

So, why is the onboarding process for novice developers so bad? Is there room for improvement?

# How do we onboard today?

Free and open-source has grown staggeringly in quantity and quality in the last thirty years, but a developer's first interaction with such software hasn't changed much. You visit the website, hopefully quickly locate the document describing installation, read more documents about how to use to the software, and if you're lucky you will encounter a document describing the contribution process. Code-hosting websites have mostly converged into a duopoly (thanks to our wonderful [GitHub](https://github.com) and [GitLab](https://gitlab.com) overlords), so most projects use the same tool to send changes ([`git`](https://git-scm.com/)) and track community contributions (issue boards, pull requests), but the educated guesswork doesn't change.

Worse still, [Contributor License Agreements](https://en.wikipedia.org/wiki/Contributor_License_Agreement), project branching rules,

So to recap: there is a lot of consistency in the where and the what, but how is still tedious. Many developers, especially first-timers, must read documents and hope they follow instruction steps perfectly, many of which they may not understand.

# How can we onboard tomorrow?

So if the where and the what are so consistent, why can't we harness it and make onboarding free and open-source developers for their first-time (in one software project or first-time ever) more seamless. Today, many use GitHub and GitLab, and almost everyone uses [Markdown](https://daringfireball.net/projects/markdown/) for setup documentation. Developers can, and often do, write code snippets and commands to set up a project, use it, and report bugs to fix, behavior to improve, and features to add.

We don't draw the pixels on our screen, the computer does. Many web apps do not have developers write all the HTML and CSS for their webpages, the computer does.

Can't we have the computer look at the docs and set up the software for us?

In this blog, we want to explore the potential, understand past approaches, and forge a new way forward.

So, let us know, dear reader, how will we onboard you?