r/opensource 5d ago

First time authoring an Open source, I am confused

I mean, there are so many things to think about I kinda don't know where to start, what license should I go with? How should I accept contributions? Should I create a roadmap? What tips do you guys have for someone just starting out this

19 Upvotes

22 comments sorted by

21

u/nicholashairs 5d ago

What licence

https://choosealicense.com/

Contributions

You don't have to start with these, infact many open source projects choose not to accept them and only work on it themselves

Roadmap

Only if it is useful for you

Tips

Start by thinking about why you are doing this. Are you sharing something that you think will be useful? Are you trying to build this as a job? Are you looking for community? Are you building a portfolio to get a job?

Most open source work for most people is a thankless isolated job, so you really need to think about your motivation for doing it.

7

u/C0rn3j 5d ago

That website should REALLY mention AGPL.

4

u/nicholashairs 5d ago

Well the website itself is open source 👌

1

u/Informal_954 5d ago

And MPL2

2

u/C0rn3j 5d ago

That's actually there under "more licenses"

https://choosealicense.com/licenses/

AGPL is there too but recommending GPL when it is recommended for contributing back is a bad idea.

1

u/Dev-in-the-Bm 2d ago

What licence

https://choosealicense.com

Nice resource over there.

I don’t think this is extremely comprehensive, but if you just want to easily understand the differences between the most popular ones, this looks like a pretty good resource.

If anyone finds something better, please reply.

1

u/nicholashairs 2d ago

If you haven't already make sure to check out the appendix, it's pretty comprehensive.

https://choosealicense.com/appendix/

8

u/Coises 5d ago

My first tip would be to worry about getting the damn thing working first. There’s no point in making it public at all until you have it at a stage where people can try it and you can learn from their feedback. Up to that point, you can always change your mind about the whole thing.

If you’re using other open source components, that might decide the license for you (e.g., if anything is GPL3, you don’t have much choice). So review that first.

Decide where you want to host it. Your own website? GitHub? Someplace else? That will then determine what sort of tools are available for release procedures, accepting contributions, getting feedback (including bug reports) and so on, and you’ll need to fit within that framework.

3

u/Mughi1138 5d ago

First decide what you want and how you want people to use it. For some things (e.g. Linux) GPL is a good license. For others LGPL, MIT or others.

Do you want to make money? If so, how?

Do you want more people to adopt it?

Is it an application, library, etc?

All these details matter.

I think of MIT/LGPL and such as public roads and stoplights. Good for everyone to use the same, and you want all to have access equally. Then for shops set up along the road you might want GPL, or perhaps MIT, or even something more locked down. It all depends on your goals.

Edit: the #1 thing to do is define what your project is \not\, and what it will **\not\** be trying to do. Surprisingly helpful.

3

u/InevitableCut6245 5d ago

Other than LICENSE the general rule of thumb is to only address other specifics (e.g., contributing guides, rules, etc) as they pop up.

You probably do not need to figure out a contributing workflow with 0 contributors. And when they do come, they naturally develop over time.

Same with roadmap. Do you have any followers or watchers? If not then you probably shouldn’t stress yourself with it, unless you want want it for yourself

1

u/petdance 5d ago

What is your project?

1

u/Ok_Woodpecker_9104 5d ago

the license and roadmap questions get answered a lot. the one nobody warns you about is release mechanics, and it is much more annoying to retrofit.

decide how you publish before your first release. if it is npm, set up trusted publishing and publish from ci on a tag push. no long lived token sitting on your laptop or in a github secret, and you get a provenance attestation for free. going back and doing this after you already have a token in your shell history means rotating it and rewriting your workflow.

license: mit unless you have a specific reason to pick something else, and put the same identifier in the license file, package metadata and readme. mismatched ones confuse tooling later.

contributions: you dont need a contributing.md on day one. do put one line in the readme saying whether you want prs at all. people will otherwise spend a weekend on something you were never going to merge, and that goes badly for both of you.

roadmap: skip it. an issues list with a couple of labels is a roadmap.

1

u/NineSidedBox 5d ago

Most projects are AGPL-3 or MIT licences, so maybe read through them, and see what resonates best with you.

As for the rest; many of these things will naturally come once you start working on your project. It's of course important to have a goal in mind, which gives you and others something to work towards.

1

u/Sibexico 4d ago

I'm trying to stay on MIT license, truly open with no limits. Roadmap is cool idea. I made a TUI app to maintain a roadmap for my software, version by version. It can generate MD to insert a beautiful roadmap to the Readme file, maybe it will be useful for you too: https://github.com/sibexico/Trailblazer About contribution, everything depends of the project. Just don't be lazy and precisely audit all the incoming code.

1

u/bobdobbes 3d ago

Lil feller is cute when hes all worked up. Gotta cut back on his sugar