How to Choose, Use, and Extend Open‑Source Projects Without Reinventing the Wheel

Select: How to Choose an Open‑Source Project?

Focus on Business Fit

When evaluating open‑source solutions, prioritize whether the project meets your business requirements rather than chasing the most popular or feature‑rich option.

Example: A team adopted the TT cache solution to replace Memcached and MySQL, but later discovered it could not fully replace MySQL, introduced bugs, and required extensive learning, leading to unnecessary complexity.

Key takeaway: match the project's capabilities to your actual workload and avoid premature optimization.

Focus on Maturity

Prefer mature projects to reduce risk; newer projects often lack stability and may cause outages or data loss.

Assess maturity by checking version numbers (avoid 0.x), the number of companies using it, and community activity such as issue response time.

Focus on Operational Capability

Ensure the project provides adequate logging, management tools, and fault‑detection mechanisms to support production operations.

Typical checks include: comprehensive logs, command‑line or UI consoles, and built‑in alerting or failover features.

Use: How to Properly Use an Open‑Source Solution?

Deep Research and Thorough Testing

Do not rely on quick demos; read design documents, understand key configuration parameters, and conduct performance, stress, and fault‑injection tests.

Testing steps:

Read the project's design whitepaper.

Identify and verify critical configuration items.

Run performance benchmarks under realistic workloads.

Perform long‑duration stress tests monitoring CPU, memory, and I/O.

Execute fault tests such as process kills, power loss, and repeated restarts.

Apply Cautiously with Gradual Rollout

Even after extensive testing, deploy first to non‑critical services, monitor behavior, and then expand gradually.

Prepare for Emergencies

Maintain backup strategies and fallback plans because unknown bugs can cause catastrophic data loss.

Example: A MongoDB deployment suffered a crash that erased data; without backups, recovery was impossible, prompting the team to keep a mature alternative like MySQL for critical data.

Modify: How to Extend an Open‑Source Project?

Keep the Core Pure and Add a Wrapper

Instead of heavily modifying the original code, build auxiliary components (monitoring, proxy layers, management tools) that complement the project.

For instance, rather than altering Redis itself, a proxy layer such as Twemproxy can provide clustering functionality.

When Modification Is Unavoidable

If a change is essential, consider contributing a request or bug fix upstream; otherwise, ensure you have proper backups and recovery mechanisms.

In extreme cases, building a custom solution tailored to your needs may be justified, especially when you have sufficient resources.