What jumps out at me is the paragraph: "Governance and leadership reforms." in the original letter sent by the government to the university.
The other stuff is hard to make sense of, but this part is crystal clear: The authoritarian government is asking the university to restructure itself along more authoritarian lines. ...essentially Trump wants continuity of reporting lines ultimately leading up to him, and going down to the individual faculty member, student, and foreign collaborating partner. That sort of thing could come in handy for all kinds of things in the future, not just the silly demands of the present.
Services are ignored by Trump for precisely the reason you mention. The big question is: What will other countries do, like Germany, who tend to export goods to the U.S. but import services. Right now, those are the countries who would rather prevent this thing from escalating, but if escalation it must be and they run out of ammunition within the scope of tariffs on goods, where will they go next?
Tariffs on services may also be less popular with the citizens. It's not obvious that the locally produced fridge is only cheaper because of tariffs. It will be more obvious that everyone non-EU based pays more. It will also be harder to control (how will EU extract tariffs for payments I do to companies with no EU presence?)
But I don't how much about it, maybe these are already solved problems. After all VAT already exists and faces similar challenges.
Services aren't traditionally part of tariffs; tariffs apply only to physical stuff moving across borders.
That being said: I work in a services-oriented business right now "exporting" services to the U.S. and the leadership of that company is seemingly getting very worried, trying to diversify their customer base out of the U.S.
If, in the cycle of retaliatory action, they run out of ammunition with tariffs on stuff, who knows what other crazy ideas will come to the surface: Tariffs on services do come to mind, maybe restrictions around recognition/enforcement of foreign-owned intellectual property,...
Tariffs on services are much harder to enforce. There's point of entry so it's harder to check.
However, some countries have a withholding tax for services provided by foreign companies. The client is responsible for withholding the amount from any payment and paying the government.
And banks play a role in the enforcement if needed.
I'll offer a less charitable framing of the whole topic of immutable / atomic distros: This is pretty much Linux distributors deciding they want to stop doing their job (or redefine what their job is to a much smaller scope). -- I'm not saying it's not justifiable that the ecosystem may need to be reshaped in that way. I'm just cautioning people from drinking the “this is the future and the future looks bright” Kool-Aid all too easily.
The job of making a Linux distribution has always been what, in an old-fashioned term, used to be called “system integration” work. They would start with a bewilderingly huge array of open-source packages, each being developed without any centralized standard or centralized control over what the system actually looks like. Then they would curate a collection of build recipes and patches for those packages.
The value a distro delivers for the user is that, for any package “foo” that their heart desires, a user can just say “apt install foo” and it'll “just work”. There will be default configuration and patches to make foo integrate perfectly with the rest of the system.
The value a distro delivers for package maintainers is: “Don't worry about the packaging. Just put your code out as open source, and we'll take care of the rest.”
The job of a distributor is extremely difficult, because of all the moving parts: People select their hardware, their packages, and they mess with the default configurations. It is no wonder at all that Linux distributions don't always succeed in their mission to truly deliver on this. But it's a huge engineering achievement that they work as well as they do, and I think we shouldn't lightly give up on that achievement.
What we have now is basically distros going: Awwwww. Fuck it. This is too hard. I'm done with this. You know what? Instead of “any package your heart desires”, you get a fixed set of packages. The ones that everyone needs regardless of what they actually do with their computer. Instead of being allowed to mess with your configuration, we'll make your rootfs read-only. (In the case of SteamOS): Instead of doing our best to make it work on your hardware, we'll tell you precisely which piece of hardware you'll need to buy if you want our software to run on it. User: Well, that's additional money I need to spend. And, how do I install my favourite app “foo”? The one I need to actually get useful work out of my computer? Distro: Don't worry, we've got you covered. We'll provide a runtime for distrobox and flatpaks. Package maintainer of “foo”: How do I get my package out in a way that perfectly integrates with distros? Distro: Make a container. Congratulations: This is additional work you have to do now, that you didn't have to do before. And about that idea of perfect integration: You can kiss that goodbye. User: I don't know. I'm also in favour of integration. Distro: That's alright. You can share and unshare stuff between containers and the host system. This, of course, is additional work you didn't have to do before. Less work for me, more work for everyone else. The future looks so bright.
In what I wrote above, I wasn't referring to NixOS or Guix. I was thinking of the other ones (SteamOS, Fedora Silverblue, OpenSuSE Aeon, Vanilla OS, etc.) -- In fact, I think it's a bit misleading to lump them together in the same category of "atomic" or "immutable". This term has come to mean way too many different things.
To be honest , most developers would much prefer to write containers or flatpak if it just works on any linux machine.
There is no free lunch , the developer might feel that his package just got into apt magically without him doing effort but the maintainer would need to do these efforts and it might not be streamlined for the developer as much as a container created by the dev himself.
It also provides more security. Flatpaks are really neat but they aren't that used in cli world in my opinion, I wanted to make a flatpak cli and I just couldn't , so I gave up
Appimage are also nice but they also have some issues , I had created appseed which basically created a static binary from dynamic binaries automatically using zapps.app but it has some issues and i am too lazy
What kind of integration do you mean? Basically the only integration that distros do is forcing all packages into one library dependency, which is something with relatively little user-facing benefit (in fact, it's mostly to make it easier for the maintainers to do security updates). This push towards appimages and the like is basically about standardising the interface between the distro and the application, so application developers don't need to rely on the distros packaging their app correctly, or to do N different packages for N different distros and deal with N different arbitrary differences between them (and if they want to delegate this packaging work like before, they can. Not all of these various packages are put out by the author of the software).
(Now, whether these various standards work well enough, is a different question. There seems to be a bit of a proliferation of them, all of which have various weaknesses ATM, so it seems there's still some improvements to be made there, but the principle is fairly sensible if you want to a) have a variety of distros and b) not have M*N work to do for M applications and N distros)
I very much work at the coalface here, and "application developers don't need to rely on the distros packaging their app correctly" occasionally happens but is most often about miscommunication. Application developers should talk to the distros if they think there's a packaging problem. (I talk to many upstreams, regularly.) Or, more often, application developers don't understand the constraints that distros have, like we need a build that is reproducible without downloading random crap off the internet at build time, or that places configuration files in a place which is consistent with the rest of the distro even if that differs a bit from what upstream thinks. Or we have high standards for verifying licensing of every file that is used in the build, plus a way to deploy security updates across the whole distro.
And likewise packagers often don't understand that the application has been extensively tested with one set of library versions and that changing them around to fit the distro's tastes will cause headaches for the developers of that application, and that they have a vendored fork of some libraries because the upstream version will cause bugs in the application. It's a source of friction, the goals are different, and users are often caught in the crossfire when it goes poorly (and when each application is packaged N times, there's N opportunity for a distro to screw something up: it's extremely rare that a distro maintainer spends anywhere near the amount of time on testing and support as the upstream developers do, since maintainers are usually packaging many different applications, while upstream is usually multiple developers focused on one project).
Software should be written robustly, and libraries shouldn't keep changing their APIs and ABIs. It's a shame some people who call themselves developers have forgotten that. Also you're assuming that distro packagers don't care, which is certainly not true. We are then ones who get to triage the bugs.
They should, but the world isn't perfect and occasionally you do actually need to apply workarounds (which application developers also dislike having to deal with, but it's better than just leaving bugs in). Distros would run screaming from the bare metal embedded world where it's quite common to take a dependency and mostly rewrite it to suit your own needs.
And I'm not saying distro maintainers don't care, I'm just saying they frequently don't have the resources to package some applications correctly and test them as thoroughly, especially when they're deviating in terms of dependencies from what upstream is working with. And much as the fallout from that should land on the distro maintainer's plate, it a) inevitably affects users when bugs appear in this process, and b) increases workload for upstream because users don't necessarily understand the correct place to report bugs.
The place where my argument is coming from is that the MxN nature is pretty much inescapable.
> What kind of integration do you mean?
See? The "integration" is something you only notice when it breaks (or when you're working through LFS and BLFS in preparation for your computer science Ph.D.) -- This kind of work is currently being done pretty well, so it rarely breaks, so people think it doesn't even exist. Also notice that a linux distro is what's both on the outside and the inside of most containers. If debian stops doing integration work, no amount of containerization will save us.
So, what kind of breakage might there be? Well, my containerized desktop app isn't working. It crashed and told me to go look for details in the logfile. But the logfile is nowhere to be found. ...oh, of course. The logfile is inside the container. No problem, just "docker exec -ti /bin/bash" to go investigate. Ah, problem found. DBUS is not being shared properly with the host. Funny. Prior to containerization I never even had to know what DBUS was, because it just worked. Now it's causing trouble all the time. Okay, now just edit that config file. Oh, shoot. There's no vi. No problem, just "apt get install vi" inside the container. Oh "apt" is not working. Seems like this container is based on alpine. Now what was the command to install vi on alpine again? ...one day later. Hey, finally got my app to start. Now let's start doing some useful work. Just File|Open that document I need to work on. The document sits on my NAS that's mounted under "/mnt/mynas". Oh, it's not there. Seems like that's not being shared. That would have been too good to be true. Now how do I do that sharing? And how does it work exactly? If I change the IP address of my NAS and I remount it on the host, does the guest pick that up, or do I need to re-start the app? Does the guest just have a weak-reference to the mountpoint on the host? Or does it keep a copy of the old descriptor? ...damn. In 20 years of doing Linux, prior to containerization, I never needed to know any of this. ...that's the magic of "system integration". Distros did that kind of work so the rest of us didn't have to.
God, yes. I did some training courses over Zoom. The presenter frequently shared pdf files we had to interact with, but the Zoom download button dropped them in the Zoom container. Figuring out how to get hold of them was a pita.
Of course, the Windows users didn't have this problem. Flatpak, etc. are objectively making the Linux user experience worse.
Those aren't particularly useful examples, though. They're all things that have been artificially seperated in containers and now there's a bunch of work to punch the right holes in that seperation, because people want the sandboxing of containers from a minimum-trust point of view, and that's pretty hard to get right. Previously this wasn't a problem, not because the distros solved it, but because there was no seperation of dbus or views of the filesystem or the like.
(Dbus, much like a lot of the rest of desktop integration, is something that has been standardised quite heavily, such that you can expect that any application that uses it will basically work with it without any specific configuration or patching, unless you've insisted on fiddling with the standard setup for some reason. It used to be that the init system was an area which lacked this standardisation, but systemd has evened out a lot of these differences, which distro and apps maintainers as well as users all benefited significantly from. Most of containerisation is basically trying to do the same with libraries as well, but most projects are also trying to achieve some level of sandbox seperation between applications at the same time)
(This is one reason why I don't much like a lot of the existing approaches here: I think the goals are admirable and the overall approach makes sense, but the current solutions fall quite short)
One problem I see with the current state of the IndieWeb having not yet "taken off" is the negative selection effect you get from having the corporate web in existence next to the IndieWeb. Back in the 90s you might write a website advertising your services as an accountant in Word, save as HTML, and upload that HTML to geocities or to webspace provided by your ISP. You can still do that today. The shocking difference is that back then it made actual business sense to do that: People would just stumble across your website. You could reach actual normies. Nowadays, because of the presence of the corporate web next to the Indie Web, the normies are trapped in the corporate web and the only eyeballs your website will attract will be the people who share in your own brand of weird. They might admire the "art" inherent in your crappy HTML, but they won't hire you as an accountant. And they're probably not strong enough in numbers for this to make any business sense.
This is actually the homepage of my accountant. “Instead of building a big website, we decided to save on the money. If you need accounting done, here is where you can reach us. It just black on white with blue links.
My brother's a carpenter, and I pushed him in the same direction. "Here's our contact details, and here's a link to the instagram where we post pictures of the cool stuff we make". I think of it as a digital business card.
Reducing the dependency tree gets a bit more complicated once you consider that now you have to satisfy not only runtime dependencies for all packages but also build-time dependencies. There may be ways of cleaning that up after a build, but next time you want to emerge a new package you'll just end up having to re-build the build-time dependencies, so in practice you'll just end up leaving them there. There is an ability to emerge packages to a separate part of the filesystem tree (ROOT="/my/chroot" emerge bla), so that you have one build-time system act as a kind of incubator for a runtime system that gets to be minimal. But you'll end up encountering problems that most other Gentoo users wouldn't encounter, having to do with the separation between build-time dependencies and runtime dependencies not being correctly made in the recipes. Personally, I had been relying on this feature for roughly the last 10 years, but there has been steady deterioration there over the years and I eventually gave up late last year.
This is a good point. I've been using Gentoo since early 2004 (the dreaded Pentium IV era, Lol). Lately, I run into this with dev-lang/tcl only being need to build dev-db/sqlite. I actually think it's pretty weird that software intended to be as widely used as sqlite with as much of a free base of supporting devs doesn't just do the extra effort to use a Makefile.
I had had Gentoo continuously in use since 2003, and only very recently moved off of it (late 2024) when I tried Void Linux. On Void, buildability from source by end users is not a declared goal nor architectural feature, but you have a pretty decent chance of being able to make it work. You can expect one or two hiccups, but if you have decent all-round Linux experience, chances are you'll be able to jump into the build recipes, fix them, make everything work for what you need it to do, and contribute the fixes back upstream. This is what you get from a relentless focus on minimalism and avoiding overengineering of any kind. It's what I had been missing in Gentoo all those years. With Gentoo, I always ended up having to fiddle with use flags and package masks in ways that wouldn't be useful to other users. The build system is so complex that it had been just too difficult for me, over all these years, to properly learn it and learn to fix problems at the root cause level and contribute them upstream. Void should also be an ideal basis for when you don't want to build the entire system from source, but you just want to mix & match distro-provided binaries with packages you've built from source (possibly on the basis of a modified build recipe to better match your needs or your hardware).
FWIW: They have provisions in their bylaws (which can only be changed with the assent of their public interest asset-locked shareholder) that restrict salaries to a level that's commonplace in the industry specifically in Germany. In Germany, software engineers and managers tend to make a lot less than they do in the U.S., certainly not an amount of money that's a meaningful tradeoff for giving up rights to dividends and other distributions.
Does anybody happen to have a pointer to further research this "Steward Owned company" legal structure? Since they're based in Germany, I assume this is a translation of a German legal term of sorts, but I couldn't find the original or anything that would let me learn more about it.
I looked up the bylaws just now (mostly because I'm procrastinating). It looks like they have a gGmbH that owns 99% of the shares (by number of shares), but founders retain 99% of the voting rights. Founders' shares are barred from receiving dividends, and the gGmbH has veto rights in relation to any certain changes that would fundmentally alter this ownership structure.
Something I don't really understand, maybe you have thoughts: is there a benefit to gGmbH over the company being a wholly-owned subsidiary of a Stiftung?
They have a brief paragraph here [1] that indicates they considered these and decided against it: "The team considered several alternative ownership solutions to address these questions, including converting the business to a German non-profit and establishing a foundation. Both of these solutions had constraints, though, and neither offered the mixture of entrepreneurial flexibility and structure security they sought."
Stiftung (Foundation) generally work well if you have a bunch of money and you basically have a fixed "algorithm" that you want to execute around the money like: "Invest it all into an index fund, and in any year in which the fund returns a profit, pay out the profits to the family members of person X in the same ratios that would apply if those people came into X's inheritance". You then appoint a bunch of lawyers to serve as the board of the foundation. Because the "algorithm" is so precisely defined, the set of circumstances where the lawyers do their job wrong will be well-defined, and will constitute a breach in their fiduciary duty. There's basically no room for making entrepreneurial decisions along the way. It's a bit like taking a pile of money, putting it on a ship, putting the ship on autopilot, and giving up any and all direct control of the ship. Depending on what precisely that "algorithm" actually is, this might get you tax advantages. Or it might create non-financial positive outcomes you might be trying to achieve like making sure that your progeny will continue to enjoy the wealth you created for many generations to come while limiting the probability that any one generation can screw it all up for the later generations.
Social entrepreneurship is different from that: A social entrepreneur wants the goodwill and favourable tax treatment that comes from giving up their claim to ownership of the money generated by the business (this is what the gGmbH status does; it's a bit like 501(c)3 in the U.S.) -- But they want to retain control over the business. They want to make entrepreneurial decisions as they go, changing strategies along the way in whatever way they please, without restricting themselves too much to the execution of any predefined programme.
For context, I live in Germany and am familiar with the landscape here. Also, I would not equate a 501(c)3 to a gGmbH; gGmbH is more like a B Corp (at least in some of the states that allow it; corporate law differs from state to state in the US). A gemeinnützige Stiftung (Foundation for public purpose) is much closer to a 501c3 than a gGmbH, and a Familienstiftung (Family foundation) is closer to a family trust. (At least for tax purposes, which is the territory I'm most familiar with in this comparison).
But that's not what I'm asking about. Unlike in the US, Stiftungs in Germany (both family and public-purpose) can own an unrestricted percentage of shares -- including all of them -- in normal companies (Kapitalgesellschaften). And I'm specifically interested *not* in restructuring a GmbH as a Stiftung, which is what Ecosia decided against, but rather, I'm wondering if there are any resources available discussing pros and cons of forming a Stiftung as a holding entity, fully owning a GmbH subsidiary (such a construct is not legally possible in the US).
From my perspective, this holding structure would provide much better legal insulation (in both directions) from the founders, preserve the operational flexibility of the (operational) GmbH, while allowing distributions from the GmbH (which would, by definition of being a 100% stakeholder, flow exclusively into the Stiftung) to be distributed by the (purely administrative) Stiftung, according to the founding documents. But I've never seen such an arrangement discussed in depth, which is why I'm asking about it.
Okay, well it sounds like you're deeper in the rabbit hole than I am, then. (I also live in Germany and have a passing interest for the law, though I'm no lawyer).
Regarding your last paragraph, where you say that a foundation provides better insulation from founder control, it sounds to me like you answered your own question: Retention of control vs. insulation from control is precisely the distinction here.
Foundations are typically for people who don't have the option of retaining control, even if they wanted to, because they are typically close to death and in the process of structuring an inheritance. Handing over control to person X is something they see as a threat, because they assume that X will screw it up, so they'd rather make it so that no one can have control.
With social entrepreneurship like Ecosia, founders are typically still young and somewhat idealistic. They want to retain the control, because them being in control is not something they see as a threat. Rather that's what they see as the best possible mechanism for their company/cause retaining its idealistic values. (Also, they are looking for something meaningful to do with their lives).
A cynic might notice that you're kind of looking at regular narcissism vs. communal narcissism here.
If you wanted to structure your social entrepreneurship type business as a foundation which owns 100% of the shares in "your" for-profit corporation, that doesn't work as a "have your cake and eat it too" solution, because either that means that the trustees of the foundation are actually your boss and you're just a replaceable employee with replaceable employee wages or, if you try to pull any shenanigans to make it so that this is not the case, the trust loses its tax-free / "community interest" status. Trying to game this system is something that rich people are routinely trying to do. I'm not saying that some don't get away with it, but the authorities generally have a lot of tools at their disposal to fight this sort of thing.
Control is maybe the wrong word here. GmbHs are required to have one or more natural persons as a Geschäftsführer, which would presumably just stay the founders, so they would retain control of the GmbH. The holding Stiftung would then impose the rules under which the GmbH would issue dividends, and (presumably) also retain the ability to fire the Geschäftsführer:innen, if the Satzung der Stiftung decided to. And of course the founders could also put themselves on the board of the Stiftung for added control. Interesting side note, this would probably result in the founders being Sozialversicherungspflichtig, but that's a whole different can of worms. But the founding documents of the Stiftung could perfectly well spell out exactly the situations under which the founders could be removed as Geschäftsführer der GmbH.
What I mean by legal insulation is more that, in this holding construct, the GmbH ceases to have any financial relationship to the founders. Stiftungs are sort of... headless financial pools governed strictly by their founding documents, completely divorced from the people that created them, and the GmbH would simply be an asset in that financial pool. That means that, for example, were someone to sue the founders, even for something completely unrelated, there is no possible way that shares in the GmbH could possibly end up someone else's hands. Typically when we talk about the liability limitations in corporations, we're talking about them in terms of shielding the founders from the actions of the company, but the inverse is in my opinion just as important (if you're truly interested in forming a self-governing social organization pursuing a social good). I'm not sure if there's any examples of shares in a gGmbH being assessed as assets in a civil case; that would be another interesting question to inform the decision.
That being said, one of the reasons that I'm so interested in the idea of a Stiftung holding, is that I think it also opens up options for actual democracy within the leadership of a company, which is a fascinating idea. That isn't a requirement in a Stiftung holding relationship, but I do think it's an interesting possibility.
At any rate, I think probably the primary downside of this idea is that, like I said, I've not seen any examples of it discussed publicly. Which means you'd need to be doing a lot of the legal legwork on your own -- which means lots of time spent talking to lawyers, which would be really expensive. But I think there's some really interesting possibility for innovation in terms of corporate governance here, in a way that, like I said, wouldn't be legally possible in the US, and it definitely seems like the structure that gives the social purpose the maximum possible protection.
I 100% agree with you that a Stiftung like that (possibly with a for-profit company as a subsidiary) would be the right structure if you wanted to maximize credibility around your community-interest status.
This stuff actually gets a lot of attention from lawmakers: For example, in the U.K. you have the “CIC” (community interest company). Some 13 years ago, David Cameron tried pretty hard to motivate enthusiasm for the idea of a “third sector”, something that's not government and not for-profit. In the U.S. you also have the “L3C” (low-profit limited liability company). In Germany, you have the idea of “Verantwortungseigentum” which was on the agenda for the previous government, though they then didn't get around to it, and you had Sahra Wagenknecht making it into a big talking point for her campaign.
But I don't think a lack of legal infrastructure is really the limiting factor here: As you noticed, we do have foundations (Stiftung) of various types, as well as coops (Genossenschaft). In addition, regular partnerships (like KG, OG) have recently been opened up so that their bylaws can now prescribe a purpose that isn't for-profit. A club (Verein) which in and of itself isn't for-profit, can have a sort of dual identity because it can become the proprietor of a sole proprietorship with a for-profit purpose (at least I seem to recall reading that such a thing is possible). Oh, and, of course, a corporation can, in theory, own 100% of its own shares. I recall reading about that, just please don't ask me where. You can basically wipe out ownership that way, without being subject to the stringent rules around foundations.
So, legal structures are as powerful and flexible as they are underutilised: I think it's the psychological side that explains why.
Usually, even if you have very good intentions, your best bet initially is to start your entity as a for-profit. Being able to operate cheaply and without cumbersome decision-making structures beats lofty aspirations for any business that just gets started. Not turning a profit in a given year (and not paying taxes because you don't turn a profit), is an option you always have. (There's no special paperwork needed for that). In fact: Not having any profit to worry about when it comes to your structure is the likely outcome. Having a profit and trying to decide how to make it so that your profits won't corrupt you in your idealism is a problem you would quite like to have! (Again: From the perspective of a founder who is just getting started).
Then, the day comes where you turn a profit quite regularly. And, at that point, once the flywheel has got going, truly giving up control will be psychologically difficult.
Very much agree in terms of the best strategy being simply to start a plain-jane Kapitalgesellschaft, probably either UG or GmbH, and go from there.
It is indeed possible to have a so-called "kein-Mann GmbH" where the company has bought back all of its shares, though my understanding is that it's a bit of a legal grey area, and certainly not settled law.
I agree that the legal infrastructure is almost certainly there, at least in the sense that there are absolutely plenty of lawyers and lawmakers that specialize in this area. My point is simply that, because it's so much less common, basically every situation ends up being unique, which means that the work that the lawyers are doing is almost always a one-off, which makes it really expensive. And so it's just not worth the effort.
https://purpose-economy.org/en/companies/ gives an impression if you click through to the company descriptions, they tend to explain what is meant. Otherwise the term seems to be understood in English, there is a wikipedia article that seems correct to me. Or was that one missing the information you seek?
> 1) Brain drain the world. Work visas for [...] literally anyone who produces value.
So, to put it in terms of the Hitchhiker's Guide to the Galaxy, they want to drain the rest of the world of everybody but hairdressers and marketing experts?
:-) Just to be clear: Referring to Douglas Adams here, who obviously meant that as satire. [1]
Of course the serious core here is this: It's assumed here that it would be a trivial matter to be able to see who is adding value and who isn't. I would question that assumption.
The other stuff is hard to make sense of, but this part is crystal clear: The authoritarian government is asking the university to restructure itself along more authoritarian lines. ...essentially Trump wants continuity of reporting lines ultimately leading up to him, and going down to the individual faculty member, student, and foreign collaborating partner. That sort of thing could come in handy for all kinds of things in the future, not just the silly demands of the present.
reply