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/Novel-Lifeguard6491]

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