For what it's worth, I plan on reviewing the code this weekend and trying to answer the following as best I can: 1. How much (and where) do the two libraries overlap in architecture and design goals? 2. How much effort would be required to modify each library to produce reusable, shareable modules? 3. Would this reusability have negative impacts on either library (e.g., reduced performance, increased memory usage)?
I'll report back with what I find. Regards, Matt J On Fri, Feb 20, 2026, 8:20 AM Elliotte Rusty Harold <[email protected]> wrote: > On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski <[email protected]> > wrote: > > > > Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > > > I agree: Collaboration on reusable code is a better way. > > > I agree too. This has two prerequisites: > > 1. Reusable code > 2. Collaboration > > Neither of those is easy to satisfy nor should either be assumed. > Reusable code is probably the easier one to guarantee. You just need > to find at least three existing projects that already have code doing > the thing you're proposing to write a library for. You have one. There > could be others. > > Collaboration is much tougher. You need active developers who are > willing to contribute over the lifetime of the project. Even if you > have them today, you could lose them tomorrow. Code that you > contribute to a different project instead of your own will now be > blocked on the availability of reviewers and might not be released for > years, if ever. This is where Apache Xerces is currently stuck, for > example. > > Genuinely reusable code is helpful, but splitting your own work into > separate parts in separate projects owned by different teams, people, > and organizations is a very risky strategy. The presumption should be > not to do this. Good evidence of benefit is needed before I would > attempt that. > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
