Dennis DoomenOct 22, 2024
I've been an #opensource developer for a long time now, but only in recent years have I realized that many of the practices we use in open-source are just as applicable in traditional development teams. Unless your entire company consists of just a handful of developers, you're inevitably going to face team #scalability challenges. A great solution to this is breaking down your codebases into separate repositories (cont'd)
Show threadDennis DoomenOct 22, 2024

that are individually releasable—provided you carefully design the #dependencies between them. Even if you're not splitting your codebase for scalability, there will always be components that you may want to share with other teams.

I'm a big proponent of treating internal code the same way open-source developers do, often called #innersourcing. This means anyone should be able to fork a repository, suggest improvements, and feel (cont'd)

Show threadDennis Doomen
confident and informed enough to understand what's expected. To achieve this, the repository should have a comprehensive README, high-quality code with static analysis, clear contribution guidelines, thorough documentation, proper test coverage, a well-defined #branchingstrategy, #SemanticVersioning, and a build pipeline that can be tested and adopted locally. The service hosting the source code (cont'd)
Oct 22, 2024 at 2:05pmWeb
Show threadDennis DoomenOct 22, 2024

should support forks without requiring write access and provide extensive code review features. GitHub is obviously ideal for this. In short, we should apply the same principles that make open-source projects successful.

#avivasolutions #consultancy #lessonslearned

Show threadDennis DoomenOct 23, 2024
How do you facilitate teams collaborating to each other's codebase?
Show threadDennis DoomenOct 28, 2024
Do you see the value of forks in GitHub?