Johann,

Sounds good. I did end up checking out the SIS code and it looks really
interesting. I can definitely picture commons-geometry in there. It would
be a good chance to introduce some cool new features in the library, such
as vector buffers of some sort, new file format readers/writers, and new
algorithms. I'd be willing to help out with that when you're ready.

Regards,
Matt J

On Mon, Feb 23, 2026 at 4:03 AM Johann Sorel via dev <[email protected]>
wrote:

> > Hi.
> >
> > Le ven. 20 févr. 2026 à 14:20, Elliotte Rusty Harold
> > <[email protected]> a écrit :
> >> 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.
> > These are all real questions which we should tackle.
> > It's depressing that we've been asking them for years, without coming
> > up with anything but "collaboration is too complicated", even between
> > ASF projects.  Even more frustrating is that AFAIK, the "Commons"
> > project was originally started to do just that!  For a long time, we've
> been
> > totally open to committers from other ASF projects; yet no synergy has
> > ever emerged (as far as I remember correctly).
> >
> > I hope that it will be different this time.  [Thank you, Johann, for
> reaching
> > out.]
>
>
> No problem, but we are not there yet :).
>
> On my side I also have to make sure it would be okay with the other PMC
> and with my boss.
> And see how much regular time I can be allowed to work on this.
> So don't get your hopes up to much, this is not something we planned to
> do this year.
>
> My questions were to check the state of those libraries and if it would
> be worth it.
>
>
> Johann
>
>
>
> >
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to