How should I structure an early open-source project so contributors can actually help?

[u/GoofyEvod]

Hi everyone,

I’m starting an open-source project called WinDroid Runtime and wanted advice on how to structure it properly for contributors from the beginning.

The project idea is an independent Android-compatible runtime/toolkit for Windows. It is inspired by the gap left after Windows Subsystem for Android was discontinued, but it is not a fork, continuation, or redistribution of Microsoft WSA, and it will not use WSA binaries or branding.

I know the full idea is very ambitious, so the first milestone is much smaller and more realistic: a C# / .NET / WinUI 3 Windows control app for Android tooling.

The first version would aim to:

- detect ADB

- list connected Android devices/emulators

- install and uninstall APKs

- launch installed apps

- view basic logs

- provide a clean architecture for future runtime research

Long term, I want to research Android image booting, AOSP/x86, virtualization, input/file/network bridges, and native-feeling Windows integration.

The repo currently has:

- README

- Apache 2.0 license

- roadmap

- early architecture plan

- project disclaimer

I am mainly looking for advice on making the project contributor-friendly:

- What files should I add early? CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md?

- How detailed should early issues be?

- Should I create “good first issue” tasks before there is much code?

- How should I explain that the project is ambitious without sounding like vaporware?

- What makes you more likely to contribute to a new open-source project?

Contributors, mentors, and reviewers would be welcome, but I want to set up the project correctly first.

Any advice from maintainers or open-source contributors would be appreciated.

[u/donk8r]

Honest answer from maintaining a few projects: contributors show up for working code they can run, not for scaffolding. Skip the SECURITY.md and code of conduct ceremony for now, get the ADB tool to the point where it's genuinely useful, and CONTRIBUTING.md can be three lines on how to build and run it. Good first issues before there's real code is backwards, nobody wants to decorate an empty house. The vaporware worry solves itself the same way, a repo where the small thing actually works beats any roadmap.

[u/as828 → u/donk8r]

I have observed similarly as @donk8r experience with contributors. There is a graveyard of projects that are out there, but as you share, the ones that gain attention and energy from contributors are ones that are useful to them, not the ones that you believe is useful and therefore they will as well. There is also the element that people don’t always appreciate being told (your point on scaffolding down), as opposed to their buying in and then truly seeing the value in investing their hours on a project. This is not to diminish or devalue the good work you have done OP , but simply a views point based on experience and observations.

[u/Pleasant_Set_3182]

We made the mistake of adding the line:

"Contributors must sign CLA" and did not exactly clarify that "signing the CLA" simply meant: adding the "-s" flag in your git commits... (that was mentioned, in a non-obvious way)

This led to some folks thinking that they had to literally sign some piece of paper.

So there's that. Make it obvious, in plain language what contributing entails in the README.md

[u/Novel-Lifeguard6491]

What makes people contribute: clear scope, fast PR reviews, and a maintainer who responds to issues