Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Naming of the Service vs. Library pattern

Open
#355 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Domain
documentation

Research direction

Read the Service vs. Library pattern linked in the issue and the related discussion in #353. Compare the proposed alternative names and clarify which name best matches the pattern; done means the naming question is resolved and the pattern is updated accordingly.

Written by the indexing model from the issue text.

Description

:book: Type - Content Work

While discussing some improvements to the Service vs. Library pattern (details in #353), @robtuley and I spoke about the naming of the pattern. Would a different name make it easier for the readers to understand the pattern?

Repeating some info from the PR below.

From me (@spier):

If you were to name this pattern, how would you call it?
I am asking because the pattern describes an approach that I might call "Library over Service" or "Separate Service Deployments" or "InnerSource with separate deployments".
I don't see the pattern really describing a comparison of InnerSource projects in both release approaches (Library + Service) but rather only focusing on the Library approach.

From @robtuley:

I also find the pattern name confusing, for similar reasons to yourself by the sounds of it.
"Service vs Library" sounds like 2 patterns being compared, this pattern is "Library" but that term doesn't describe this pattern well to me personally because it is applied more widely in our context.
I'd call this pattern "Separate Team Deployments" or maybe "By Use Deployments", and like your suggestion of "Separate Service Deployments".

Dominant language
HTML
Stars
853
Forks
206
Avg merge
1d 23h
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InnerSourceCommons/InnerSourcePatterns

All issues in InnerSourceCommons/InnerSourcePatterns

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.