How open-source projects work

Almost every robot you will build stands on open-source work: the operating system on the companion computer, the flight or motion firmware, the CAD and PCB tools you drew the parts in. Before you send a single change to such a project, it helps to understand how the project is organised and, above all, what the licence lets you do. Most beginner mistakes in open source are not technical. They are about expectations: who decides, what is allowed, and how people prefer to be approached.

What "open source" actually means

Open source means the source files are public and a licence grants you specific rights to use, change and share them. The second half matters more than the first. Code that is merely visible on the internet, with no licence, is not open source: by default the author keeps all rights, and you may not legally copy it into your own project.

A project is a small organisation made of a few roles:

• Users run the software or build the hardware and report what breaks.
• Contributors send fixes, features, documentation or translations.
• Maintainers decide what gets merged, cut releases, and answer for the quality of the whole. They are usually volunteers or a small team with a day job, and their time is the scarcest resource in the project.

Keep that last point in mind for everything in this course. A good contribution is one that costs the maintainer very little attention to accept.

Licences: the rules of the game

A licence is a contract-like grant that travels with the code. The two broad families are permissive and copyleft.

A permissive licence says: do almost anything you like, but keep our copyright notice. A copyleft licence adds: if you distribute a modified version or something built from it, you must share your source under the same licence. The reasoning is that copyleft keeps improvements flowing back to the community, while permissive licences make the code easy to adopt, including inside closed products.

Robotics projects use a mix of these, and a project can change its licence over time, so always read the LICENSE file in the repository you are working with rather than relying on memory or a blog post.

What licences mean for firmware

Firmware is software, so software licences apply directly. The case that surprises people is GPL on a device you sell or give away. When you flash GPL firmware onto boards and hand those boards to someone, you are distributing the software, so you owe those people the corresponding source code, including your modifications. Under GPL-3.0 there are further rules about letting users install their own modified versions on consumer devices.

With a permissive licence such as MIT or Apache-2.0 you can ship the firmware inside a closed product, as long as you keep the notices. Apache-2.0 adds a patent grant from contributors, which is why larger organisations often prefer it.

What licences mean for hardware

Hardware is less tidy. Copyright protects the expression of a design: your schematic file, your PCB layout, your CAD model, your drawings. It does not obviously protect the physical function of the object, and patents are a separate system that a copyright licence does not cover. Software licences like GPL were written with source code and binaries in mind, which map poorly onto a circuit board.

That gap is why hardware-specific licences exist. The CERN Open Hardware Licence family comes in strongly reciprocal, weakly reciprocal and permissive variants, written for design files and for people who manufacture from them. Documentation and images are often put under a Creative Commons licence instead. A hardware project commonly has three licences: one for the firmware, one for the design files, one for the docs. You will do exactly this in lesson 5.

How the project is run

Open that repository and look for the same set of files, because most projects have them:

• README: what the project is and how to start.
• LICENSE: the rules above.
• CONTRIBUTING: the maintainers' own instructions for sending changes. This is the single most important file for you. Policies on code style, testing, sign-offs and where discussion happens differ between projects, and this file is where they are written down. Do not guess; read it.
• CODE_OF_CONDUCT: the expected behaviour in issues, reviews and chat, and what happens when it is broken. It protects newcomers as much as anyone. Following it is the price of admission.

Then the working surface of the project:

• Issues are the public to-do and bug list. A good issue says what you did, what you expected, what happened, and your versions and hardware. A vague issue costs everyone time.
• Pull requests are proposed changes, which you will make in lesson 4.
• Discussions, forums or chat are where open-ended questions belong, rather than the issue tracker, when the project says so.
• Releases and tags are named snapshots such as v2.1.0. Users should build from a release, not from whatever is on the main branch today.
• A roadmap or milestones show what the maintainers plan next. Before proposing a large feature, check that it fits. A brilliant patch that points the project in a direction the maintainers do not want will not be merged, and that is not personal.

Why this structure exists

Every item above answers a problem that appears once many strangers collaborate. The licence answers who may do what. CONTRIBUTING and the code of conduct answer how to behave when nobody has met. Issues and roadmaps answer how a small team decides among thousands of wishes. Releases answer how users get something stable while development carries on. When a maintainer asks you to follow a rule that feels fussy, it is usually because the project hit the problem behind it once already.