Exercise 3: Stable Governance vs. Active, Still-Evolving Fork — Possible Solution ==================================================================== WHY POSTGRES1-1'S OWN MATERIAL IS DESCRIBED AS A STABLE STATE OF AFFAIRS ------------------------------ Per this chapter, "postgres1-1's own MySQL-Oracle-vs-Postgres- community contrast described a stable, long-standing state of affairs — Oracle has owned MySQL for well over a decade, with no active dispute currently reshaping that arrangement." MySQL's own ownership by Oracle, and Postgres's own community-driven governance model, have both been settled, unchanging facts for a very long time — there's no active negotiation, no ongoing legal or licensing dispute currently in progress that could meaningfully change either project's own governance structure in the near future. A learner reading postgres1-1's own material today gets an accurate picture that will likely remain accurate for a long time to come. WHY THIS CHAPTER'S OWN HISTORY IS DESCRIBED AS ACTIVE AND STILL EVOLVING ------------------------------ Per this chapter, "this story is different in kind: a genuine, still- evolving fork with real, ongoing consequences for compatibility and feature parity between the two now-separate codebases." Unlike the MySQL/Postgres situation, the Elasticsearch/OpenSearch split is a comparatively recent event (2021) whose consequences are still actively unfolding — the two codebases continue to diverge (or converge) as each project keeps developing independently, and per this chapter's own "A More Recent Twist" section, even Elastic's own licensing position itself has already changed again since the original 2021 split (the 2024 AGPL addition). This is why the chapter explicitly states it "deliberately doesn't attempt a final verdict" on which engine is "better" — because the actual, current answer to that question is something that could change again, in a way the MySQL-vs-Postgres governance comparison simply isn't expected to. WHY THIS STRUCTURAL DIFFERENCE MATTERS ------------------------------ The practical consequence is that postgres1-1's own material can be treated as a durable, background fact worth understanding once; this chapter's own material has to be treated as necessary CONTEXT for search1-9's own separate, dedicated, up-to-date practical comparison chapter, precisely because the underlying situation is still moving. This chapter itself acknowledges this explicitly, deferring the actual "which one should I pick" verdict to a chapter whose content can better stay current as the real situation continues to develop. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why the MySQL/Postgres comparison is treated as settled background (no active dispute reshaping it) versus why the Elastic/OpenSearch story is treated as ongoing (a recent fork with continuing divergence and even further licensing changes since), using each chapter's own stated reasoning rather than treating the two historical comparisons as equivalent in kind.