Re: Current state of Apache Commons Math and Geometry

Matt Juntunen <[email protected]>
Newsgroups gmane.comp.jakarta.commons.devel
Message-ID <CAEqMBkQkO0Or1MS2bYyr_OLGOiMzK0usK0XpywzAUJBCQQNseA@mail.gmail.com>
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]
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.