Add Follow the Sun Development pattern

[abduljaleel]

• Addresses cross-timezone collaboration challenges in InnerSource
• Provides structured handoff protocols and async-first practices
• Level 1 (Initial) pattern ready for community validation
• Fills identified gap in current pattern collection

[welcome]

💖 Thanks for opening this pull request! 💖 The InnerSource Commons community really appreciates your time and effort to contribute to the project. Please make sure you have read our Contributing Guidelines.

If you are submitting a new pattern, the following things will help get your pull request across the finish line! 🏁

• Confirm that you have used our pattern template. Please remove any placeholder text and sections that your pattern did not need.
• We run a number of automated checks on your PR. Please review the output of those checks on the PR itself, and see if any issues got flagged that you can fix yourself.
• Make sure you have added your new pattern to the list of patterns in the main README.md. If you are unsure where to add your pattern, just let us know by commenting on your PR and we will help you.

This project has a small number of maintainers, volunteering their time to this project. So please be patient and we will get back to you as soon as we can. If we don't acknowledge this pull request after 7 days, feel free to chat to us about it in our Slack workspace.

[spier]

@abduljaleel thank you so much for your contribution. We are glad that you found us :)

One general question about this pattern:

Assuming that there is a regular team of 8 people, and they are working together on the same project.
These 8 people are distributed globally, i.e. working out of different locations and timezones.
Would the exact same "Follow the Sun Development" approach apply to them?

Or asked differently: Is there a need for the "Follow the Sun Development" approach to be adapted to InnerSource, or can it be used as is?

Thank you for your help and insights into this topic!

[abduljaleel]

This pattern does require InnerSource specific adaptation because:

1.	Scale sensitivity: InnerSource teams are often smaller and need lighter-weight approaches
2.	Governance model: Community-driven vs. hierarchical decision-making
3.	Resource constraints: Must work within existing organizational tools and processes
4.	Contributor motivation: Voluntary vs. assigned participation requires different engagement strategies

However, the pattern would benefit from clearer differentiation of when full FTS protocols are needed versus when simpler async-first practices suffice.

Given the need for differentiation for smaller vs large teams, will it help to add below as pattern improvements:

1.	Add decision criteria: When to use this pattern vs. simpler alternatives

2.	Include lightweight variants: “Minimal Follow the Sun” for small teams

3.	Provide cost-benefit guidance: Help teams assess if the overhead is justified

[spier]

@abduljaleel the pattern improvements that you are suggesting sound great. If you have time to work those in, amazing!

Some further question:

1. Are you aware of any online references about the FTS approach that are worth mentioning in the ticket? I did take a quick look myself and found things like this. Would be great to find references of a known organization talking about their FTS approach, and when to use it (and when not to use it).
2. Is the organization that you work at running into the issues outlined in this pattern, or how did you come across it?
3. Just out of curiosity, are you using AI to help write this pattern as well? We have run experiments with AI for a couple of pattern drafts in the recent months. Always good to hear from others how they are approaching this.

[amburi]

@abduljaleel Great work! I’ve had experience working with the Follow the Sun development model, and it’s exciting to see the same approach being applied in the InnerSource world.

[spier]

Hi @amburi, great to see you join the conversation.

I know it might be a stretch but do you have time to review this pattern?
Key question for new patterns like this: Does this solve problem related to InnerSource?

If you have time to do the review you can do so by using GitHub's review function, where you can leave inline comments for the author, etc.

Would be great to get your help here but if you don't have time, totally understandable as well. So no pressure.

[amburi]

Hi @spier, I'd love to review this pattern. I will share my thoughts/review comments by tomorrow.

[amburi]

@abduljaleel I’m interested in your view on how this supports InnerSource principles—especially collaboration and mentoring. I’ve added a few review questions in the review.

[amburi]

@abduljaleel Trusted Committers across time zones are valuable—but is this strictly required for the pattern, or a scaling recommendation? How does the pattern work if Trusted Committers are concentrated in one time zone?

[amburi]

Does "primary contact" refer to the owner of the task?

[amburi]

How can decision disagreements be managed? How to handle always-on expectations (burnout) for contributors in non-dominant time zones?

[amburi]

Automation of basic project information is a good idea; how can we define one source of truth for the project?

[amburi]

For shadow decisions, since the workflow mentions recordings, please add the missing summary→ADR step with a 24–72h publish target and a brief async review window so the “why” is visible across regions.