I’m not sure MS will have much luck using EEE on GPL projects.
When .doc format was extended, they then ‘extended’ it with proprietary features, then extinguished competition by locking them out of those additional features.
You can download all Github projects, and wikis, because they’re all based on Git, and the only ‘extensions’ particular to Github are CLI specs, and issues, which can also be ported easily.
You can download all Github projects, and wikis, because they’re all based on Git, and the only ‘extensions’ particular to Github are CLI specs, and issues, which can also be ported easily.
Technically correct (although you’d need to migrate Github Actions also, which is yet another beast), but politically misguided. Migrating from Github as a organization (a closed pool of contributors) is a rather easy task that’ll take you a week worth of work.
The actual problem is that Github acts as a centralized social network for developers and represents the biggest contributors pool across the FLOSS ecosystem. As a volunteer-run project, moving away from Github means loosing much visibility and many contributors. I’m not saying it’s not worth it, but it’s not just a technical question of whether that’s possible.
Also worth noting that we have many alternatives but none of them are specified/interoperable. I have a longer blog post exploring that question if you’re interested.
I’ve never had practical trouble downloading scripts and identifying the creators, because I use package managers. I think the best general solution for normal end-users getting packages they can trust is always a well-audited package manager.
And of course, the GPG key solution seems to work well enough for coders.
I can’t imagine a general solution to Github workflows. I use Gitlab’s CI for LaTeX documents, but terraform code would obviously be better for other projects. I sounds like disparate solutions is a good idea.
Thanks! The RSS feeds are generated by Zola, the SSG i use (and contribute to sometimes).
I think the best general solution for normal end-users getting packages they can trust is always a well-audited package manager.
I entirely agree! And i personally don’t think that distro packaging is dead (or should die), but i do believe there’s a crisis in the field: nix/guix certainly represent a far better model in a day and age where there are dozens of thousands of packages to maintain for many architectures.
The Debian/Fedora packaging system makes it more complex than it has to be to just push an update because most of the steps have to be done manually. Of course, i appreciate when some packages are maintained by trustworthy people inspecting the changelog, but no distro has the energy to do that for all packages…
I can’t imagine a general solution to Github workflows
Do you mean for CI/CD? I don’t understand why we need Github Actions at all. If only we could have a standardized protocol/vocabulary (like ForgeFed/ForgeFriends) to subscribe to updates across different forges, we could have pretty basic/standard tooling performing tasks as we like them.
They can still use the data for oppo research, poaching talent, and in combination with their linkedin property they can steer the most productive FOSS developers into proprietary jobs. Targeted brain drain.
I’m not sure MS will have much luck using EEE on GPL projects.
When .doc format was extended, they then ‘extended’ it with proprietary features, then extinguished competition by locking them out of those additional features.
You can download all Github projects, and wikis, because they’re all based on Git, and the only ‘extensions’ particular to Github are CLI specs, and issues, which can also be ported easily.
Technically correct (although you’d need to migrate Github Actions also, which is yet another beast), but politically misguided. Migrating from Github as a organization (a closed pool of contributors) is a rather easy task that’ll take you a week worth of work.
The actual problem is that Github acts as a centralized social network for developers and represents the biggest contributors pool across the FLOSS ecosystem. As a volunteer-run project, moving away from Github means loosing much visibility and many contributors. I’m not saying it’s not worth it, but it’s not just a technical question of whether that’s possible.
Also worth noting that we have many alternatives but none of them are specified/interoperable. I have a longer blog post exploring that question if you’re interested.
Nice blog post, and always nice to see RSS feeds.
I’ve never had practical trouble downloading scripts and identifying the creators, because I use package managers. I think the best general solution for normal end-users getting packages they can trust is always a well-audited package manager.
And of course, the GPG key solution seems to work well enough for coders.
I can’t imagine a general solution to Github workflows. I use Gitlab’s CI for LaTeX documents, but terraform code would obviously be better for other projects. I sounds like disparate solutions is a good idea.
Thanks! The RSS feeds are generated by Zola, the SSG i use (and contribute to sometimes).
I entirely agree! And i personally don’t think that distro packaging is dead (or should die), but i do believe there’s a crisis in the field: nix/guix certainly represent a far better model in a day and age where there are dozens of thousands of packages to maintain for many architectures.
The Debian/Fedora packaging system makes it more complex than it has to be to just push an update because most of the steps have to be done manually. Of course, i appreciate when some packages are maintained by trustworthy people inspecting the changelog, but no distro has the energy to do that for all packages…
Do you mean for CI/CD? I don’t understand why we need Github Actions at all. If only we could have a standardized protocol/vocabulary (like ForgeFed/ForgeFriends) to subscribe to updates across different forges, we could have pretty basic/standard tooling performing tasks as we like them.
They can still use the data for oppo research, poaching talent, and in combination with their linkedin property they can steer the most productive FOSS developers into proprietary jobs. Targeted brain drain.