In the first case, the project maintainer/owner was asked to make the change, and it's implied possibly paid to do so. But as previously stated, that particular case wasn't that bad, since the only thing shady there was the use of some dark patterns to bias people towards Kite while somewhat obfuscating that it would disclose their source code.
In the second case, because they hired the project maintainer/owner, that made Kite effectively the project owner, and as was established, the thing people are really angry about was the second case. So yes, Kite is 100% to blame as the project owner (via hiring the project owner).
I suppose there are probably two lessons to learn here. First, if something is a major open source project that's widely used, it would be a good idea to make sure there are multiple project owners/maintainers with veto powers to keep each other in check. That wouldn't stop a company from hiring ALL the owners/maintainers on a particular project, but it would at least increase the difficulty, particularly if they were geographical distributed potentially forcing the company to work out employment in multiple countries.
Secondly, when a company acquires an open source project, they are obligated to follow the norms and expectations of the open source community, at least if they don't want to have said community complaining about (and eventually forking) their newly acquired project. Since presumably they found value in the project, it's in their best interest to not upset the community thereby reducing or destroying that value. As such, any action they take that could be construed as giving favor to their commercial products over others (particularly other open source products), or which would introduce ads into the project, need to be considered VERY carefully and great care needs to be taken around how those sorts of things are implemented and introduced. In particular making sure all your ducks are in a row by making sure you get buy in from a significant portion of the products user base before rolling the changes out.
Comments
In the first case, the project maintainer/owner was asked to make the change, and it's implied possibly paid to do so. But as previously stated, that particular case wasn't that bad, since the only thing shady there was the use of some dark patterns to bias people towards Kite while somewhat obfuscating that it would disclose their source code.
In the second case, because they hired the project maintainer/owner, that made Kite effectively the project owner, and as was established, the thing people are really angry about was the second case. So yes, Kite is 100% to blame as the project owner (via hiring the project owner).
I suppose there are probably two lessons to learn here. First, if something is a major open source project that's widely used, it would be a good idea to make sure there are multiple project owners/maintainers with veto powers to keep each other in check. That wouldn't stop a company from hiring ALL the owners/maintainers on a particular project, but it would at least increase the difficulty, particularly if they were geographical distributed potentially forcing the company to work out employment in multiple countries.
Secondly, when a company acquires an open source project, they are obligated to follow the norms and expectations of the open source community, at least if they don't want to have said community complaining about (and eventually forking) their newly acquired project. Since presumably they found value in the project, it's in their best interest to not upset the community thereby reducing or destroying that value. As such, any action they take that could be construed as giving favor to their commercial products over others (particularly other open source products), or which would introduce ads into the project, need to be considered VERY carefully and great care needs to be taken around how those sorts of things are implemented and introduced. In particular making sure all your ducks are in a row by making sure you get buy in from a significant portion of the products user base before rolling the changes out.