>Kay wrote udev. He is now a lead contributor to systemd...
Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.
Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).
Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.
From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.
Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.
Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).
Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.
From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.