Money has never been this project’s bottleneck. None of the active core developers have an interest in working on diaspora* full-time (which includes me), so raising money is not a concern. We have more than enough money to support the project’s infrastructure.
Hiring external developers with no relation to the project in its current form is not productive. You’d need way too much onboarding effort, and you’d need to spend way too much time on feedback and reviews to a point where it wouldn’t be sustainable anyway. You can’t scale OSS projects like diaspora* by just throwing more human resources at it.
We’ve had, at some point, legal representation set up so that people and companies could donate to an actual non-profit to support diaspora* development. The actual income of that was so low, it didn’t even cover the operational costs.
As for Germany specifically, founding and registering an e.V. does not magically turn your org into a non-profit. You can get declared a non-profit as any legal entity, but that requires a lot of extra work. Doing so only increases the operational costs of an entity as it complicates bookkeeping to a point where you’re almost forced to hire an accountant just to keep compliance, which is expensive. The actual benefits in tax reductions are purely theoretical. If you hire staff as a non-profit e.V. or as a gGmbH, you’d still have to pay Lohnsteuer for your employees, and you’re actually also gewerbesteuerpflichtig if you make more than € 35k per year, which you have to to be able to effort maintaining the e.V. and hiring staff. While this is an exceptionally German-English paragraph, similar caveats apply for 503(c)(3)s in the US.
Most of the time, founding a non-profit for a project the size of diaspora* is nothing but a waste of time and money. You can just as easily collect donations via, for example, the Open Collective Europe ASBL/vzw. It’s just that the potential income isn’t worth the effort.
Adding more features to a project isn’t helping a project. Most of the time, even though people claim they want new features, in the end, there isn’t any significant usage of those features - or maintenance. We’ve seen this in this project many times before: sharing geolocation was a huge feature request, but once it was implemented and the novelty has worn off, nobody is using it. Lots of people requested an instant messaging integration, but once that was implemented, most podmins didn’t even bother setting it up, and those who did saw low usage, and nobody ever wanted to fix bugs after the initial implementation happened.
A thing that lots of projects tend to forget is that “do one thing and do it well” isn’t just a random idea that someone came up with. There’s a reason for that, and frequently, just adding more features to a project is only causing harm.
Splitting the project away from pod maintainers is a deliberate choice, not an accident. And my personal opinion is that that’s a good thing if the project’s goal is actual decentralization.
Most of the “other” projects have… issues. Matrix, for example, has a nice product, but I’d guesstimate that over 75% of the entire network are hosted by Element, the company. This not only includes @matrix.org, but also some “custom” nodes like Mozilla’s Matrix homeserver. That’s not decentralization - that’s running a central infrastructure with a bunch of white-labeled custom domains. That’s a bit like adding your own domain to Google Mail - that’s not going to make your email any more decentralized. The same is true for Mastodon, where a gigantic chunk of users are on mastodon.social, which is hosted by the project team - and a bunch of other big nodes like fosstodon.org are hosted by the same company - “masto.host” which is a one-person company that’s hosting all its instances in the same OVH region. The reliance on a central authority for both project’s health is immense, and I don’t want to encourage other projects going the same route.
Companies that host OSS project instances are cool because it allows the project to gain significant revenue (in the case of Element, it’s enough money to hire a lot of employees who do great work), but it actively subverts the idea of having a decentralized platform in the first place.
We as a project do not want to handle user data, and we don’t think that it would be a healthy thing for the “central project team” to also offer diaspora* hosting, which is why our pod at pod.diaspora.software only hosts official project accounts and will never be open to registration. In practice, this principle has already been violated by us “fostering” two big pods until the migration feature is ready for prime time, but I see no incentive to hoard even more user data in our control.