Also, if we agree that GitHub copilot enables you to be more productive as a developer. Can we argue that it could help open-source communities by helping them finish projects faster?
We made Axolo specifically for that, we believe pull requests (or merge requests in your case) should not take too long to be reviewed and you should be able to discuss them easily. Axolo creates a Slack pipeline to automatize conversations with the creator and assignees/reviewers.
I worked at different startups while being a freelancer. The one that provided the best environment for me to work as an engineer:
- Great welcome packages (computer all set up, some cool swag, and a person I could easily ask questions)
- Unlimited budgets for tools I judge necessary
- Time for learning. One company had a moment once every two weeks where an engineer would present his findings about a new technology. You could choose to share anything you thought was interesting for others in your team. Could have been a git functionality, a new framework, or a tool.
- Daily standups and very few to no meetings during the day. => This is important. One startup I worked at had me in meetings half a day and was expecting me to ship like I was working a full day.
Interesting reasoning and I like the questions you ask yourself.
This makes me think of Polaris Methodology I heard from a french tech team:
Sometimes you just need to get the code working to advance in your feature or whatever you are trying to build so you add a TODO to your code; The problem is that you never come back to it.
The Polaris methodology is that after 6 weeks of the sprint, they have 2 weeks of 'rest'. Rest time is used for code that hasn't been completely finished, code that "smells". You use those two weeks to refactor what is fresh in your mind and whatever you feel needs to be made better.
Other licenses may be open source, but you'd probably have to get lawyers involved to make sure. So it's better to just pick a license which the OSI considers Open Source.
If you don't want to rely on just the OSI, you can also check what the Free Software Foundation, Debian and Red Hat think of the license you've picked.
Moreover, picking an existing popular open source license is important because a and b being opensource licenses does not mean that they are compatible, i.e. they could still have mutually-incompatible requirements that prevent anyone from releasing a combination of a-licensed and b-licensed code.
It will help you understand the relevant parts of the law (copyright, patent, trademark) as well as helping to differentiate between various types of Open Source licenses.
