If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall "too big to fork", I love this expression
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall Why build thousands of warships for our navy when we can have one big beautiful warship the size of a thousand warships.
-
@david_chisnall "too big to fork", I love this expression
there's a certain parallel w/ the “too big to bail” problem we had break in 2008 when the banks were small-N multiples of GDP and hence couldn't have been bailed out without printing Euros and Germany said `nein`
if too big to fork happens, it deffn will happen in Europe, for the irony if for no other reason
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall So much agreed. I would star and boost this multiple times if possible.
Unfortunately we live in a system where building sustainably like this is disinsentivised, but still, here's to hoping.
-
@david_chisnall So much agreed. I would star and boost this multiple times if possible.
Unfortunately we live in a system where building sustainably like this is disinsentivised, but still, here's to hoping.
Here is the one-sentence summary for politicians:
Do you want to create an environment where corporations are more powerful than parliaments?
Hopefully that's enough to get their self interest on side.
-
Here is the one-sentence summary for politicians:
Do you want to create an environment where corporations are more powerful than parliaments?
Hopefully that's enough to get their self interest on side.
@david_chisnall I am unfortunately not at all certain that our current government in Finland would answer that with a "no".
-
Here is the one-sentence summary for politicians:
Do you want to create an environment where corporations are more powerful than parliaments?
Hopefully that's enough to get their self interest on side.
Do you want to create an environment where corporations are more powerful than parliaments?
I think my (Australian) government operates with that as a guiding principle, by moving formerly public jobs to the private sector they remove any public oversight, and there's also a job waiting for them when their term is up.
-
Do you want to create an environment where corporations are more powerful than parliaments?
I think my (Australian) government operates with that as a guiding principle, by moving formerly public jobs to the private sector they remove any public oversight, and there's also a job waiting for them when their term is up.
@the_decryptor @david_chisnall
Unfortunately, that job might also be both more profitable and more secure than waiting for the next elections.
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
Thanks for writing this. You're right
With Nostr being a protocol, as opposed to an single open source project, then I think it might fit in nicely there. The EU could encourage development of many Nostr projects without the 'centralization' risk that you mention
But I guess I'm naive, and I shouldn't obsess about Nostr
(I tried to zap you, but you don't see to have an address set up) -
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall multiple great threads happening on this very topic, just sad it's taken so long for people to start thinking critically about it.
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall I would also like to add that besides less pressure, the smaller companies will also often have conflicting interests, making the political pressure balance out more as well.
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall Well, an important factor behind this is the Reagan-era deregulation of conglomerates. EU has a more functional competition regulation system, so the forces here likely do not automatically favour the development of such huge black tech-holes.
But it's an important concern to keep one's mind on when one's dabbling in regulatory affairs.
-
@david_chisnall I am unfortunately not at all certain that our current government in Finland would answer that with a "no".
@ananas @david_chisnall Swedish Moderaterna would be throwing money at you before you even finished the question
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall These US tech companies are regulated by the weakest of the weak Irish regulators in Ireland. The pressure needs to be put on Ireland and not screamed into the void
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall I agree. The important thing that authorities should promote is not company size but common standards, so that many different services offered by many companies remain interoperable
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
In essence it goes back to #OpenStandards and #Interoperability.
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall ... but not for there owner class and we all only exist so the owner class can burn the planet and hoard everything...
-
If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:
One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:
- The smaller companies can exert less political pressure on governments.
- A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
- A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
- A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).
Pivoting from big US tech to big EU tech would retain most of the same problems.
And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.
As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).
Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.
Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.
Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.
@david_chisnall this is just the old conflict between efficiency and robustness played out in a new arena (not that new, TBH). The usual pattern is everyone goes for the efficiency until the failure mode hits them, then they overcorrect on robustness.
-
@david_chisnall multiple great threads happening on this very topic, just sad it's taken so long for people to start thinking critically about it.
@cmthiede @david_chisnall Well, for *certain* people to start thinking critically about it while ignoring other people's warnings for years.
-
@cmthiede @david_chisnall Well, for *certain* people to start thinking critically about it while ignoring other people's warnings for years.
@aerique @david_chisnall IKR, been talking to the walls since 2004, just never "vibed" right with people. It's not exactly something one would WANT to ever "trend" in the 1st place, but here we are, atop the precipice.
