Pgbackrest is no longer being maintained(github.com) |
Pgbackrest is no longer being maintained(github.com) |
all of these various 3rd party backup tools use these things. Mostly it's QOL stuff that you get from a 3rd party tool. We use barman, very happily: https://pgbarman.org/
Is it me ore I am seeing more and more projects being unmaintained due to financial and/or mental fatigue?
[1] https://blogs.gnome.org/chergert/author/chergert/
[2] https://github.com/nvim-treesitter/nvim-treesitter/discussio...
[3] https://discourse.gnome.org/t/stepping-down-as-libxml2-maint...
After a lot of thought, I have decided to stop working on pgBackRest. I did not come to this decision lightly. pgBackRest has been my passion project for the last thirteen years, and I was fortunate to have corporate sponsorship for much of this time, but there were also many late nights and weekends as I worked to make pgBackRest the project it is today, aided by numerous contributors. Every open-source developer knows exactly what I mean and how much of your life gets devoted to a special project.
Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.
Like everyone else, I need to make a living, and the range of pgBackRest-related roles is very limited. I can now consider a wider variety of opportunities, but those will not leave me time to work on pgBackRest, which requires a fair amount of time for maintenance, bug fixes, PR reviews, answering issues, etc. That does not even include time to write new features, which is what I really love to do. Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.
I will post a notice of obsolescence and archive the repository. I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.
Again, many thanks to all the pgBackRest contributors over the years. It was a pleasure working with you!
what if, bare with me, what if, after a certain amount of time, a certain amount of "requests", a code library can be given to a genAI to maintain; no improvements, no extra features, just bug fixes? This could continue until either someone picks it up, or the open source solution becomes irrelevant, not enough "requests".
Yes, lots of details to work out.
> I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.
I completely understand having to back out of maintenance on an OSS project, but why also slam the door closed on someone taking over? There may be someone very qualified willing to step up, and that could give your existing users continuity.
This feels analgous to deciding to stop maintaining a community garden, but rather than let your neighbor step up, you decide to salt the ground so it can never grow there again, telling your neighbors "you can pull up my plants and move them, but you can't use all the ground and roots that are already there." It just feels bitter.
yes
see https://news.ycombinator.com/item?id=47921198 for start
Bailey: maintaining a popular project is not that much work.
What?
many people here don't read the articles, and that's not going to change. (on today's internet, jumping from the site you want to be on to a site with unknown UX patterns is fraught)
but people here do read the comments, so having important details from the articles in comments here improves the quality of comments here, at least if you value staying on topic.
I'd personally do the same. I wouldn't want to be bothered by the future maintainers' choices and get feedback/flak for it. It's a well-known and well-respected way to cycle the name with a "-ng" or "-nx" prefix to signal that this is the newer project with a different set of maintainers.
Being MIT, while is not my favorite license, doesn't give free license to grab and run with things.
Honestly, in my eyes, 3.8K or 38K stars mean nothing, because Open Source is not about you [0], to begin with.
[0]: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Finding a successor is also not easy nor cheap (in regards to time).
3.8k stars and the name is years of built up trust with you, not with the person you gave it to.
Oh yeah, I'm sure you will find lots of competent people. Like Jia Tan, for example. I've heard he is very competent.
Why is it never the responsibility of the people using it?
If anyone cares enough they will. People didn’t care enough to pay, so maybe no one cares enough to fork and be the new unpaid custodian
The alternative to this seemingly bitter approach is handing over the trust they built to some unknown person who can do whatever they want with the data in a lot of PostgreSQL databases around the world. I think I prefer the bitterness here over blind trust.
If no one cared enough to support the project, why does anyone care enough now? It all sounds hollow. Nothing bitter about it.
When you work on a project, any project, you have a responsibility. At some point we all can stop, and become free to not have that responsibility.
EDB has been in private equity(PE) hands since 2019 with out managing to ruin it so far. The ownership in PE hands seems to be pretty stable, so it doesn't look like the typical pump/dump mess you often see from crappy PE money.
No, it's not. You can still contact the author and ask them to transfer the name to you.
Also saying that GitHub has unknown UX patterns made me lol.
dumb "journalists" especially have this backwards mindset.
I had just last year prepared a detailed guide for reliable postgre backups to local volume as well as cloud storage, using pgBackRest, for my own projects.. pgBackRest have worked so well for me
https://github.com/freakynit/postgre-backup-and-restore-guid...
Thanks to the author for all the time and effort he put into this project..
Also, many programers have spent their entire funds on tokens, so neither are left with extra money nor time.
Tiered pricing license... tiering based upon annual company revenues... should start super low for small companies (free for individuals), and jump to thousands of dollars per year for 10+ milion revenue companies.
I understand that this might not fully be in the spirit of open-source, but, what's happening currently is way worse.. where giant companies rip off the hardwork of open-source software maintainers without compsensating them adequately.
Why would anyone do that? If the person who was most passionate about it for over a dozen years has given up because it was never worth the trouble; what fool would think things will be different going forward?
This is the curse of OSS.
The source is still available. Maintaining your own copy and/or paying someone to do it is an option.
While you're at it, look at all the projects you depend on that you would similarly be sad about losing, and set up those donations today.
Not the fact that he made the decision he made.
A fair amount of people work here at orgs on here would absolutely be able to swing couple of hundred bucks per month in sponsorship or licensing or donations for a critical tool in their infra toolkit without lot of effort.
Particularly so, with the rising frequency of AI deleted my prod posts.
It was the only solution that seemed to take restoring and validating as seriously as “taking a backup” which lead to an unfortunate situation with my employer. (details here: https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-bac...)
This is really a major loss. :(
Anybody know how WAL-G and Barman compare?
Sad to see competitor go, I think there's lots of room for improvement here, & C over Golang is particularly nice when postgres wants to run on system without overcommit
With WAL archiving you need to wait for a WAL segment to finish before it's backed up. With streaming backups the deadtime is minimized. At least that's as far as I understand this, I didn't get to try this out in practice yet.
If this is really much more than a personal project "for fun, on my leisure time", and it became an actually serious product-level project that provides good value in commercial environments for people, there's clearly an opportunity for a for-profit company to step in and cover that niche. But that'd require that users became customers and actually departed from their money to pay for it :)
I guess most will switch instead to asking who's the next project maintainer to work on it, to whom the new bug reports and complaints can continue to be sent for free. But if there's money to be made by using a tool, there should be money paid for using it too. We "just" need to find the new generation of FOSS Financial Sustainability solutions that actually work! Donations don't make the cut.
That applies to local shops as it does open source projects.
Obviously, all contributors have some form of copyright, which may or may not have been waived depending on whether there was an ACL in place and jurisdiction. So he would need to get permission from the copyright holders, maybe in exchange for a percentage of the profit.
But it's MIT license. We can open a company tomorrow, take that code, and start selling it. Further development and improvements of the code could be trivially done openly or behind closed doors. FWIW the author themselves could do that if they wanted.
What's the next-closest thing? wal-g? barman? databasus? I only get to cosplay as a DBA.
So this was the problem, I thought Snowflake would pick up the sponsorship of this project but since it is a competing database it doesn't really make much sense.
I really wish many critical OSS projects get the sponsorship they need to continue.
Otherwise the software industry is in real trouble.
Forking it just passes the buck onto another maintainer with the same problem, this time without the original creator maintaining it.
"AI driven backups with smartest world class models optimizing every byte stored via deep AI analysis."
With that added, a million dollars is just chimp change. YC alone would be adding them to all the seasons multiple times over summer, winter and monsoon etc.
I doubt that they have sponsored an OSS project or made it sustainable.
They're two non competing verticals. It's a shame Snowflake decided to shrink Crunchy Data's community presence.
General idea still stands, but it is not like this just disappeared and backups will stop working.
Of course there is always the risk it goes out of business like any other company, but it’s not funded like your typical small open source project and doesn’t even allow open contributions (not necessarily a bad thing IMO but it’s just a totally different type of project).
I am therefore quite sad to see this happen. It won't be easy to get feature parity with this great product.
I sincerely hope this is a reversible decision, or perhaps the postgres project could even absorb it into contrib.
Software Engineers suddenly feel like they're fighting for their lives for employment, and time won't be "wasted" maintaining OSS for free.
We all need to eat.
I think that’s what the author would want. People to keep using it until it doesn’t work anymore.
I'll have to look at the alternatives again, I think that was mostly WAL-G and Barman. It looks like Barman doesn't support direct backup to object storage, unfortunately. And I find the WAL-G documentation very confusing. What I'm looking for is WAL streaming and object storage support, to minimize the amount of data that can be lost and so I don't have to run my own backup server.
How many actually contributed back to keep it going?
I am feeling a slight unease using such a recent project for things as important as the database. But the polished interface combined with the easy docker deployment made me use it anyway. Restores need some permission tuning on PostgreSQL but otherwise happy.
They are very proud of their github star acquisition curve [0], the "blessing" by Anthropic [1]
But I have yet to verify the Anthropic claim.
[0] https://www.reddit.com/r/selfhosted/comments/1q94uu9/selfhos... [1] https://www.reddit.com/r/ClaudeAI/comments/1rklvr7/anthropic...
However, it's really sad that pgBackRest has been closed, because I was led by pgBackRest in some sense when started Databasus
Did you encounter any issues or limitations?
keyword: desperate... until the metric becomes the target, and stops being a good metric.
In other words when it comes to FOSS contribution, developer time can be donated but tokens can't - so as we move into agentic code era all FOSS development carries a cost unless it is purely done by hand (which more often it isn't).
Not saying this is what is going on here but it's presumably a factor if the author was looking for an employer to sponsor development with his labor (and tokens).
I guess it’s anthropic donating the tokens because they give me about $5k of API tokens for the $200 I pay them.
Chatgpt also has similar https://developers.openai.com/community/codex-for-oss
[1]: https://www.postgresql.org/docs/release/17.0/#:~:text=pg%5Fb...
Highly recommended. Definitely worth taking a look: https://pgmoneta.github.io/
hopefully some of the big co's step up & pay a retainer to keep the author going.
Also, pgBackrest lets you do the majority of the backup from a physical standby, which is VERY nice for removing the load off production.
None of these seemed like issues, until we looked at pgBarman, and suddenly realized how nice that would be.
I'll take a look. Thanks!
https://github.com/aiven-open/pghoard seems like a good option too, but I haven’t tested it yet to have a solid opinion.
It's great because it's a completely clean save from a shutdown state, so when we need a scratch copy of a database it only takes as long as cloning whatever snapshot we want (depending on how far back we need to to), then starting a scratch jail that runs from those clone filesystems. When finished, just shutdown scratch and delete the clones, it's like it never happened.
**Backup types**
- **Logical** — Native dump of the database in its engine-specific binary format. Compressed and streamed directly to storage with no intermediate files
- **Physical** — File-level copy of the entire database cluster. Faster backup and restore for large datasets compared to logical dumps
- **Incremental** — Physical base backup combined with continuous WAL segment archiving. **Enables Point-in-time recovery (PITR)** — restore to any second between backups. Designed for disaster recovery and near-zero data loss requirements
Or why not hire the guy?!
Seriously. Is nobody using this at a level where hiring the primary maintainer is a good idea?
If you thought this project had value, you could’ve contributed to it. You probably still could.
Or, if you think its value is worth $0 (to you), maybe it’s not really that sad (to you).
People are expressing sadness as if there was nothing to be done about it, but, of course, there’s a really straight-forward thing that could’ve been done about it (possibly still could).
Those that paid, or did any kind of contributions upstream are entitled to be sad.
Others should consider this is what happens to that lego piece in Nebraska, when no one contributes, and everyone uses it.
Something burning down is a tragedy, beyond anyone's control. It's also possible to love something for its beauty, and be sad that a globally historic monument suffered such an act of god that the irreplaceable art and craftsmanship is gone forever.
Something closing down, perhaps because there was not enough money to sustain its continued operation, when tens of thousands or hundreds of thousands of people were using it? That's a perfectly appropriate time to remind folks, "if you like free software, consider donating to help sustain the almost full-time effort it takes to keep packages like this alive."
Op said, "this is sad [because] I've been using this," and the implication is, "I want to keep using this but now I can't because it's gone" and making the connection that "one way to prevent this from happening to other packages you like is to contribute financially."
Not everything is about money.
I can use Pgbackrest in my side project which does not generate any money. Maybe my side project is another open source project where no one give me money, but I'm still contributing to the open source ecosystem, maybe I reported bugs which help everyone.
There are so may details and possible reasons to not give money and use open source software, but your negative and naive comment totally miss them.
He was paid to work on it. That stopped, he continued to work on it in the hopes he could find someone who would hire him to work on it.
That wasn’t true, no one has funded it.
So due to the economic system he no longer maintains it.
That’s your economic system at work. No one is pretending it isn’t there, this is the outcome of it
The business model is as follows: Open source maintenance produces recurring costs (developer salary, infrastructure costs, etc) but these costs are fixed and do not scale with the number of users, only with the development effort. This means the ideal financing structure would be a cost plus system where the maintainer gets paid a salary and the customers (businesses) are spreading the cost among each other so that each business ends up paying less than if they had built or maintained the project in-house.
The problem here is that the costs are variable and depend on the number of participants and their individual willingness to spend money and how that effects the viability of the project as a whole. Participating businesses need some sort of guarantee that they won't be stuck with all of the costs and that there are other participants who will chip in. At the same time, once there is a sufficient number of participants, the participating businesses don't want to overpay. They may commit to a monthly worst case bill of $5000, but if the total bill is $10000 and there are 100 participating businesses so that each business could only pay $100, said big spender would want the option to lower their spending down to $100 if possible and let others carry more of the financial burden.
With this sort of arrangement, funding open source software would be rational, since the amount you save by freeloading is insignificant compared to the risk of the project being discontinued due to freeloading.
On top of that, for availability (and minimizing deadtime), we have 2 replicas using streaming replication. If the lead PG crashes, one of the replicas is promoted to lead (and starts accepting writes), and we "only" lose the writes that haven't been sent over the streaming replication.
You can fully eliminate that window of data loss with synchronous replication (vs the default asynchronous replication - which we use). The write slowdown (replica network round trip + 2nd write at replica) isn't worth it for us
I've been working on Open Source software for 30+ years. There's no money in it, if your idea for making money is "accept donations". I don't like it, but it's a fact. If you want to make money, you have to make something that isn't free (and even then, if you give away the most valuable parts, as in "open core" licensing, you probably still won't make enough money to make the development worth it).
When I was young and driven by idealism and optimism, I assumed that with enough users I'd be able to ring the cash register somehow. Turns out not so much. We got the users, the money never came. There are a few outliers, but there probably aren't a lot of opportunities to found a Red Hat today.
Companies need to jump through legal and accounting loopholes to donate, they very much prefer a simple purchase, which is nice! But setting up actual purchases is a whole different ordeal with open source, now the question is why is the company paying for something that's free?
Source: my own 5-stars open source project with 500k+ active users that paid for 3 coffees in total over 10+ years. I still get like $2 sometimes after a long while.
Not necessarily even code contributions. It could be professional networking. It is a bit different if the person is not a stranger.
It's a bit of a niche as it is, so that's going to be rough in any kind of pricing model, as a large part of that niche is either homebrew types and the other commercial industry that will likely require some more integrations and customization.
I suggest GPL or AGPL because their copyleft clauses make them hostile towards platform providers who might otherwise seek to profit from your work without paying.
As long as they keep releasing sources of their own modifications -if they ever do any-, the rest is fair play.
Why can't others that just used the tool feel sad? It is supposed to be used, it's the whole reason for it to exist; not everyone using it will have technical expertise or money to contribute to it, feeling sad about it when it solved issues for someone is a completely normal response.
The reason for something to exist is someone finds joy doing it. Especially when they are unpaid.
The sadness should be focused on his inability to support himself with a tool that clearly a lot of companies, and people are using and gaining value for.
The sadness doesn't need to be focused anywhere, you can feel sad for more than one thing at a time. People can be sad that a tool they think is great, have relied on, and has been important for their use case is going away while also be sad that such a great tool doesn't get enough support from companies. Both can be true, no need to control what people can or should feel.
I've never heard of this project before and I still think it's a bummer that a tool people liked and that the maintainer cared about was unable to find backing. I was never going to support it; I just heard of it for the first time today and I don't use it! I'm still sad. We're not robots here. We're fellow developers, and we know it's tough out there.
I didn’t even use pgbackrest but I’m still sad to see this.
I should have checked the comments first to determine my eligibility to be sad about this issue, before I had feelings that upset the sadness gatekeepers.
Most OSS projects simply don’t have that kind of weight or discipline to follow SQLite’s footsteps.
It did not have to, they could(and some would argue probably should) have gone the normal copyright with public use license route. But I suspect that because US government code by default is in the public domain(the US government has means other than copyright to protect it's IP) and this code was originally written for a cancelled US government project. That was their default mindset when they wanted to release it.
Note that I am using a sort of editorial they here, I think it was largely the effort of one person.
It is probably telling that with fossil, a supporting project to sqlite, they went the more normal route and released it under copyright with a BSD type license.
I like the idea of public domain(some things belong to us collectively), but it does raise an interesting question if a private individual can place something in the public domain. Are you allowed to give up your rights?
SQLite is in a whole different league when it comes to funding, corporate support, etc. There are commercial contracts directly tied to its ongoing support and development. As far as I understand SQLite is Hwaci’s bread and butter.
OP pointed out that many people stated they were sad. OP also pointed out it's likely few of those who were sad also contributed money. For a project whose maintainer said, essentially, "I can't keep doing this for free," the connection for most is obvious: "we (individuals and corporations) need to keep paying for the things we use and love if we want to keep the things we use and love."
OP did not say, "don't complain to me if you didn't personally try to save it."
I am an active open source contributor.
> This is the curse of OSS.
There are examples of failing forks. And there are examples of forks that became better than the original. It is not possible to generalize this into one or the other solely via a curse-of-OSS conclusion. Funding will always be an issue; but funding is not necessarily the main or only criterium as to whether a project fails or succeeds.
Just because someone gets tired of working on something eventually doesn't mean everyone else will immediately feel the same way.
I don't think they are "hoping" someone else will take it, exactly. They're just done with it. That's how I read it, they liked working on it, but it wasn't financially sustainable, the project is now over, and my reading is they are sad about it.
“And many programmers, they say to me, “The people who hire programmers demand this, this and this. If I don't do those things, I'll starve.” It's literally the word they use. Well, you know, as a waiter, you're not going to starve. So, really, they're in no danger.”
- Richard Stallman in 2001 admitting his ideology can’t explain how a programmer can eat
In my opinion, though this is HN heresy, the free software ideology and ethos was naïve, utopian, and clueless about how power works, from day 1. His dream is literally structurally impossible, capitalism or no capitalism, so long as humans need money to eat.
September 26th, 1983:
"Dear Mr. Stallman, it is I, gjsman-1000, a time-traveler sent back to tell you to rethink your upcoming GNU project because you are currently clueless about how power works. Yes, you may be able to code up an impressive prototype compiler and revise it until your fingers bleed. Yes, a decade later some zealous followers may follow your lead and maintain it on the bleeding edge. Yes, two decades later others will perhaps start an open source compiler project to wrest control from your successful compiler that is largely maintained without your direct input. And yes, three decades later your compiler team may even merge in new features and improvements that came from the other compiler. But heed my ominous warning: four decades later I will not be able to remember my original point, for time travel is dangerous business and has adverse effects on short and long term memory."
And yes the free software ideology is as naive as a puppy. Every serious individual understands this. Most HN-ers are in a fairly specific bubble (income brackets, geo-location, political leanings, upbringing, the whole package); of course to them this is "heresy". This is well-understood. Happily for me and many others around here, karma farming is not the goal so we don't mind getting some gray arrow treatment every now and then.
I am not even fan of Stallman. I think it is ok to produce close software. But starving argument is just not it.
Some who are opposed to capitalism seem to think that anyone who wants to trade their talents and hard work for more than the minimum, are exploiting anyone who wants or needs their product.
Not all open source licenses are copyleft licenses (e.g., MIT very much isn’t), but at the very least copyleft licenses make it much harder to exploit open source code commercially without giving back in some way, whether that’s code, or cash for a commercial license.
Not perfect, by any means, but definitely an improvement over more permissive licenses.
I am aware of how much I’m starting to sound a bit like RMS in my old age.
In this case the provider would of course have to comply with the AGPL and release their modifications as you mention, but it's important to note that No FOSS license protects at all against, for example, just offering the code as a service. It's the exact reason why Mongodb changed licenses and then a stream of commercial products started to change into "Source-Available" licenses in the recent past.
Too complicated. Make it GPL (not MIT) and offer dual licensing.
Those corps that need it but are GPL-phobic can have a different license, and can pay for it.
My org theoretically makes hundreds of millions, unfortunately none of that money is ours. So I get forced into a procurement process for anything that costs more than (ridiculously small limit), and get stuck using the worst in class because it's cheaper.
for example, adding support, bug fixes, corp-friendly licencing and pricing models, private code/package repos, code/package signing, etc. Providing biz ppl to be available for meetings, legal protection, PII, etc.
To foster goodwill, they could even send some of the profit back to the original maintainer, ala pikapods: https://news.ycombinator.com/item?id=31312682
I'm not sure this worked out as well as we thought it might do for the musicians.
If you don't have a discretionary spending limit that will accommodate it, then trying to get OSS through procurement is difficult. Who is providing the support contract? What level of indemnity insurance is the supplier covered by? Can you get a spread of three quotes from competitive providers?
Not to mention that if the supplier isn't VAT/GST registered, the accounts department can be operationally incapable of accepting an invoice or issuing payment.
Not malicious, this is best practice for a large organisation that needs to prove that it is not doing fraud. But it does present a huge obstacle to buying from small organisations, startups, and one-person OSS maintainers.
I thought a while back there were some products that had dual licenses, a fairly open license for private use, use in small companies, but requiring purchase and/or contribution back when used in something like a cloud providers SaaS.
I like open source, but I also can understand the nagging feeling when your (and your contributors work) is used for pure corporate greed.
I like this idea, but the devil is in the details. "profit" is less defined than revenue. You have to specify your accounting principles. What counts as an expense that deducts from revenue to help define profit?
It's not impossible, but there's a lot more variance depending on locality, business structure, etc. than there is with just "revenue".
Of course, I suspect it all comes down to whether the entity offering the license is large enough and well-enough legally armed to force an audit of the organization taking the license. If they're not able to do that, it's all self-reporting anyway.
Maybe they mean their org makes a lot of money the money for their parent corp, but little of that ( goes into / is reflected in ) their own orgs budget?
People who don't want tiered licenses could definitely just mit it and walk away of course.
I do like the idea of paying back the original maintainers otherwise people could sandbag projects to fork them later.
What do you mean by this? A FOSS product that has a paid packaged version?
See all these multinationals paying close to no taxes in the countries where they operate.
One way around it is that you get an existing consultancy, who is already on the corporate approved suppliers list and has jumped through all the hoops, to resell the product. They take a hefty cut, usually, but can also pay more punctually (in general large corp purchasing departments negotiate/demand looong invoice payment deadlines).
That still leaves more problems - like the sales cycle, it can take two years or more for a large corp to go from an "we want to buy this" from a department head to an actual purchase order from procurement. You could short-cut that if you were already an approved supplier, and had a team who knew the process and could respond much more quickly to the insane amount of bureaucracy involved.
You'd need to be large (large corps hate buying from small companies), well-funded (so there's no argument that you'll run out of funds, or not be able to compensate them if something goes wrong), heavily insured (see above), with a team who knows their way around everything that a large procurement department could throw at you. You could pro-actively try getting on the approved suppliers list for every large corp in a sector, and then advertise your services to OSS/startups/small corps, who would be your customer.
Not stupid, certainly. I've heard worse ideas ;)
I'm not sure making the payment part easy is going to help that much. The ideal, of course, is to get the cost under the departmental discretionary budget; most large corps allow small purchases to go through with less oversight.
Atlassian managed to do this during their initial B2D selling-to-devs stage, so it might be worth reading up how they did it.