To get started with the new gig, I wanted to take a step back from the existing services and projects to think through what the jobs of the ideal Postgres extension ecosystems of our dreams might look like, and then the tools to do those jobs. I wrote up all that I could think of, plus ideas and recommendations from my Tembo colleagues, in this Gist. I'd love your feedback and additional ideas — especially for anything I missed! LMK what you think!
@theory That's a lot to churn on, even for a start!
I think the metadata standard might consume a lot of time, until that is settled. Many other tasks on your list can be worked on by a small team, but this one needs extensive input from the community.
@theory You also raised the language question. I know you like #Perl, but over the past three years I've seen how really complicated it is to find allrounder with also extensive Perl knowledge. And we were just trying to maintain Rex ...
@ascherbaum@theory
if by Allrounder…Extensive you mean someone happy to mostly work in JS or Python or ... for a salary but still has deep Perl-fu, that's scarce because maintaining depth requires continued focus.
Some have moved on professionally while having ongoing emotional bond to #perl ; some of us are rent-by-the-hour pay-as-you-go consultants, not cheap but we don't burden the balance-sheet the rest of the year.
@BRicker@theory That's what happening here as well. We have people in the company who have a good understanding of #Perl. Yet they don't want to work with it (anymore).
@ascherbaum@BRicker@theory Is it that they don’t want to work with #Perl, or that they don’t want to work with your particular Perl codebase?
What I’ve seen time and time again is that management doesn’t want to devote enough resources to control the risk of lifting grotty #LegacyCode to a better state. So it just keeps accreting and discouraging those who could make it better.
Add comment