How does GitHub co-pilot relate to InnerSource?

[rrrutledge]

Co-pilot helps with code reuse (via code suggestions). This is related to InnerSource, where a common goal is code reuse. How can we be intentional about this?

[rrrutledge]

Is this generative AI - style tooling? Metadata tagging? Or specifically GitHub co-pilot?

[rrrutledge]

How do we have modern tools help us with code reuse.

[rrrutledge]

There are thoughts about having Co-Pilot or AI have visibility to company-internal code, but that is not something that we can see being available in the near term.

[rrrutledge]

AI could help to review pull requests - e.g. letting the submitter know that they could improve their documentation or code submitted with the code request.

[rrrutledge]

AI and co-pilot may proliferate code duplication if it is inserting code snippits everywhere.

[rrrutledge]

Maybe the AI could find duplication and suggest places for consolidation.

[rrrutledge]

Could the AI realize that you are writing duplicated code and suggest that you use an InnerSource project instead?

[JustinGOSSES]

There was discussion on copilot on PRs, there is a new feature for PRs that as of this writing requires getting on a wait list https://githubnext.com/projects/copilot-for-pull-requests

[JustinGOSSES]

Speaking to using generative AI API and not GitHub Copilot..... I've experimented with applying Azure-OpenAI API and the RAG pattern for code discovery. I used open source repositories by my company, but could be done for InnerSource as well. Created embedding of ~300 READMEs, then wrote natural language prompts to describe the type of repository I would like to find if it exists "front end library focused on mapping in JavaScript that can be used with React". It does a good job with that type of query and comparison queries. Example: "explain to me why I would want to use library A vs. library B."

My code is not public as it was part of an internal hackathon, but you can experiment quickly on a smaller scale with the GitHub + python example in semantic kernel. https://devblogs.microsoft.com/semantic-kernel/semantic-kernel-embeddings-and-memories-explore-github-repos-with-chat-ui/ Modifying that example to include many repositories and not just a single one wouldn't be too hard for demo purposes.

For production, you'd have to worry about things like access and authentication unless you limited it to repositories everyone in your organization can already see.

[JustinGOSSES]

Also did a small experiment using generative AI to produce topic tags based on READMEs. If you're okay with tags not being correct some small percent of the time, it does great and was two order of magnitude faster to build then when I was part of a team that built something very similar with traditional machine learning methods. This type of thing is awkward to apply to actual GitHub repositories topic tags as (1) you'd be changing someone's repository (2) last time I looked you couldn't programmatically set topic tags via the GitHub API. However, it is well suited for when you have a separate website catalog of repositories, which is what sometimes exists for InnerSource. Of course, you would want to make sure the machine learning generated topic tags are explicitly labeled as such.

[rrrutledge]

Time for a Backstage plugin. It's already throwing our READMEs into some time of searchable index, I think.

[rrrutledge]

Easiest MVP of InnerSource to implement is stuff that we are OK with being seen company-wide. More granular permissions are the following step.