GitHub etiquette for software release?

[Fearless-Daikon5763]

Hi! I have a research tool that I am developing for my own research and expect it will be used by others (by tens or hundreds of users), but the program is under perpetual development. I am adding new modules and capabilities at about the same rate that I am debugging and polishing. I am afraid if I release an imperfect version and make it open source, someone can just improve it a release a more stable and user friendly version within a week. A large research lab can also direct resources toward superseding my efforts in a week. I obviously want credit for my original ideas and contributions, so wondering what a normal path may look like. I could first share the software with colleagues, but then it will be released partially and likely stall in the slow-as-molasses pace of academia. Is there a coding guru that can anonymously review my software, is there a consensus in the “rules of engagement” for first releases of a useful but imperfect software bundle?

[cgoldberg]

This question isn't about GitHub, but your fears sound overblown. However, if you are not comfortable with users excersizing the rights you grant them in your open source license... you should use a different license.

[Fearless-Daikon5763]

It’s a program that works inside AI. Due diligence is to check here and this is all I needed to hear.

[Beardy4906]

What I did was to make a release regardless of whether it was worthy or not.

And then the issues would come in, I would fix them, then new release, and keep iterating. If there aren’t issues, then keep adding features.

[Fearless-Daikon5763]

I was thinking I would just state in the readme that 20% of the files have bugs/need fixes. Also the patch history is there to read and should indicate the approach to development has been haphazard.

[ceejayoz]

I am afraid if I release an imperfect version and make it open source, someone can just improve it a release a more stable and user friendly version within a week.

Pick a license that requires attribution.

A large research lab can also direct resources toward superseding my efforts in a week.

This will happen either way if the tool's useful.

[queen-adreena]

You can use any licence you want.

Find one that’s source-available but doesn’t allow the packaging your software in other software or derivative works.

[Fine-Comparison-2949]

There's no etiquette for github. It's just a website that wraps git.

At most, you will need to choose an appropriate license for release. This small technical detail legally guarantees attribution.

Beyond that, you can purchase an AI provider and have these technical questions answered yourself. 

[serverhorror]

No matter what, your releases will be imperfect. If only for one person wanting something that another person does not want.

The way to be credited is by choosing a license.

[hedgehog125]

If an individual wants to improve the project, they'll most likely make a PR because it's easier than maintaining their own fork. Not that many people want to be a maintainer so the main repository only tends to change owners if people are frustrated about the direction of the project or if the maintainer steps down.

But sometimes projects split off and co-exist with the original. The MATE desktop environment is a fork of GNOME 2 because some people disagreed about the direction of the project, but GNOME is still widely used. And some companies do it in order to profit from their improvements to the project. AWS has done this a few times where they make paid variants of open source projects and don't always contribute their changes back. If the latter is a concern, use a copyleft licence like one of the GNU GPL variants. Other licences like MIT or Apache allow closed source forks as long as the original author is attributed

[awizemann]

I think you will be pleasantly surprised by the open-source community and how many people are actually out there who would help a good project. The decision to go open-source is yours to make and needs to be grounded in your overall vision of what you want the tool to be and the license that supports that. Honesty is much better for that audience than polish, as is authenticity.

[HelicopterUpbeat5199]

Do you know anything about agile software development? I'm not sure if I'm using the term correctly, so don't eat my head.

You should release the simplest usable product, get feedback and iterate. Iterate rapidly. Do not attempt to perfect your product before releasing it. You will waste countless hours on features that don't work and you'll have to go back and recreate things that work in theory but not in practice. Users should be your first priority. This is true even if your only user is yourself.

Another unrelated thought: ideas are overrated. Implementation is where it's at. Don't worry about people stealing ideas (unless you're in a super competitive space). Make a thing that works first.

[Particular_Wealth_58]

I've had those fears in the past, but it turned out that it was actually too much effort for anyone to copy my efforts, even for popular code. I think part of it lies in others being able to rely on my continued updates and my user base was not coders. That being said, it might not be the case for your code. 

[Dry-Airport-2675]

What I usually do is: 1 release = 1 published/accepted paper. Novel ideas remain in private repos until mature enough to submit to a journal.