Accepting donations is not the same as entering into a contract agreement where the person giving a few bucks per month entitles them to dictate how the work should be done. If people want to enter in a relationship where they get exactly what they want for the money they are giving, then they will be better off by going to a commercial provider, so that the nature of the transaction is explicit and mutually agreed.

With respect, this is a framing issue and depends on your point of view. Does a donation mean someone contracted you to do something specifically? Not really. But, will mismanagement of expectations and hostility convince someone to stop donating to a project? You’d better believe it. If you’re working full-time on a project, donations are your lifeblood. They literally put food on your table. You literally can’t afford to disregard the needs of users and admins. But of course, you are at discretion to decide what those needs actually are, and how critical they are. Nevertheless, the relationship is more transactional than it appears to be.

About the grants: AFAIK they got the grant to make federation work, which was completed to everyone’s satisfaction. If they had received a big grant from NLNet, got the money but didn’t deliver on what they promised on the application, then you could argue that they did not hold their end of the bargain. But do you it’s fair that because they got money from one part of the work that they should be responsible for all subsequent deliveries?

Overall, I think their grant from NLNet was a good thing, and I think they did good work on that. As long as their work was in scope of the grant, I don’t see a problem with that.

I’m really trying to understand where you are coming from with this. You mentioned your work on Diaspora, and I don’t know how much you were involved on it,

Community Manager, circa 2011 to 2013. I was basically an air traffic controller for GitHub issues, acted as a developer liaison, served as a face of the project to the community, and engaged on the network every single day to get a pulse on what was going on. A lot of it involved smoothing things over with people who were upset about things, resolving conflicts, drumming up volunteer coders, and indicating to core team what varying needs were across the user and developer communities. I lived and breathed it every day.

I do feel that one of the things that doomed Diaspora was that the founders mistook the attention and money they got in 2010 as an indication that they were all alone responsible in “saving us from Facebook

This is somewhat inaccurate, and here’s why: Diaspora never advertised itself as an Anti-Facebook. They were building a federated network that focused on user freedom, and it was a combination of timing and insanely good luck that their Kickstarter campaign picked up as much as it did. The whole “we’re going to save you from Facebook” thing was an invention of the media to get people to click headlines. What really doomed Diaspora was that the core team wanted to be a startup, the community wanted it to be a project, and getting the company into yCombinator had the team focus on things further and further away from their original goals.

If Ilya had learned to say “it’s not my responsibility to build everything to win a fight against a multi-billion corporation”, perhaps he would still be around. This is a little disingenuous. Ilya had a big heart and was an amazing person, but he struggled with depression, anxiety, and mental illness. There was an enormous amount of pressure, sky-high expectations, and media vultures that picked apart every little hiccup the team went through, but I don’t think it’s fair to say it was those things alone that made his passing happen. They didn’t make life any easier for him, though.

What is so bad about the developers delegating this away?

Developmental drift and code rot. Both parties can try their best to keep up with changes and adjustments, but an external resource is always going to lag behind of core. This isn’t necessarily bad, but having it in core at least kind of ensures that future development and updates have to take into account how those things are affected.

I like to think of it like this - many hands makes for a very stable project. Stable as in reliable, but also stable as in resistant to change.

Everyone is going to pull in a different direction, and it kind of averages out and slows things down.

Right now, lemmy is extremely immature. It’s amazing how well it’s held up really. There’s a lot to go to get to a solid baseline - just enough to keep

If everyone dogpiled it, someone could easily solve the image problem. Granted, that might block someone else working on the database, and changes to improve or extend federation would likely be set back as they step on each other’s toes.

We could still probably quickly get popular features quickly… For example, one person could get more useful mastodon and kbin federation going in a reasonable period of time. But then, when the core team goes in to overhaul the database or the API, now they need to make sure they don’t break it - and the person who did those changes won’t have the same vision as the core team, and now you have to either refactor the whole thing or work around it until it’s causing too many problems

Certain things can be spun off more easily than others - I think other people have totally taken over deployment of instances.

Some are good candidates but require more maturity - like if they handed off jerboa and the default web client, there’s one place that would need to be reinforced - the API.

Way down the road, they could build plug-in/mod interfaces so instances could choose feed algorithms, or individuals could come up with their own karma systems, or all sorts of other things.

To get to that point, you have to have a clear vision and stable growth though - that takes time, and is better done by an individual or small team keeping things heading in one direction

Couple of reasons:

1. It’s core. Super crucial parts of the platform should, ostensibly, be done by the core development team, who can ensure they have someone to work on it as needed. If you delegate the development of a core feature to someone who isn’t part of the core team, there is always a possibility that said person will fall off the development wagon, and the feature either languishes, or core team is stuck having to babysit a part neither of them directly worked on.

2. The people building the platform need to have a significant understanding / frame of reference for these parts and how they work. When doing future feature development, they need to be keenly aware of which features touch which fixtures.

3. Trying to delegate this kind of thing to volunteers is just such a mixed bag in terms of Quality Assurance that I cannot recommend it. You might get something great! But regardless, you’re delegating to someone who is a relative stranger, who may have done things in a hacky way that will break something else later on, or may have not even bothered with code or documentation. Worse yet: trying to reconcile a volunteer’s PR with upstream is not always a cakewalk, and this can drag on and on and on. I’ve literally seen projects with PRs open that sat in that state gradually getting adjusted, tweaked, and rebased by various volunteers who came and went, that are still open to this day.

Par for the course. I hope for them they don’t break the ethics clauses of their financing.