Which is sort of the point: Applying a patch to a package within a distribution is quicker and easier than it should be, because more likely than not it’s not being tested and reviewed properly. I’m speaking from experience. I maintain several applications within the KDE project, and developers affiliated with distributions as varied as SuSE, Debian and Gentoo send us patches regularly (thanks!). As developers familiar with the code base, we can often quickly spot obvious bugs in those patches that the authors are oblivious to, get them sorted out, and integrate the patches. If the distribution goes straight ahead and applies the patches to their packages directly without getting them upstream first, however, those bugs stay in and it’s the users who bear the cost, and the developers it reflects poorly upon. It’s unfun to learn this the hard way for all involved.

> I do want to get my patch upstream. But after this, I’m a bit wary of how to proceed. Will he/they eat me?

If he’s any good, he’ll be happy about any patch that makes the app better, and do his part to get it in. Ideally an open source developer puts the project above himself and makes sure he’s not being a single point of failure for it. And he should try to make the experience pleasant enough that the contributor will want to come back.

> What if other downstreams (of the same upstream) do not want/need those changes? Perhaps it’s a case to case basis. Some patches would probably be of interest to upstream and the general whole, while some would most probably be of interest only to a specific downstream.

Generally speaking, it’s in the interest of a given project to make their product flexible enough to accomodate a wide range of downstream needs. An easy example is making it straight-forward to swap differently branded visuals by having proper theming facilities, but there are much more technical cases, too, of course. So yes, there is certainly a lot of opportunity for the upstream project to be managed so poorly as to make downstream’s life hard despite downstream having all the best intentions, and the burden of doing the right thing doesn’t solely rest on distributions. More often than not it’s whether it’s able to balance contending needs that makes the difference between a good and a bad open source project.

> Think of it as testing it on guinea pigs and weeding out the bad patches.

I don’t think it’s desirable to abuse users as beta testers if it’s avoidable.

> Isn’t this the sort of technical and social centralization that Linus is essentially trying to overcome (re: git discussion in core-devel)?

No, those are slightly different discussions. That vendor kernel trees are an increasing problem for the Linux industry and generally frowned upon should tell you as much, though. In fact, the kernel community is trying rather hard to make it easier and easier for people to stay close to the mainline in what they ship and deploy; that was one of the main reasons for changing the development model a few years back.

> Instead of a central space for development, how about a central place for communication?

Development -is- communication, to a very large degree. That’s why I’m emphasizing the upstream project as a shared space for all involved parties.

> But I guess upstream shouldn’t always expect or demand that development should start or happen on their turf alone, or that things will always go their way. The road goes both ways IMHO.

You’re still clinging to that “us vs. them” image that you shouldn’t be having in the first place, so it seems I’m not really getting through. Rather than seeing upstream as a foreign country, see upstream as the club house for every one, a shared facility. The mantra is “involve yourself”.

@Jonas: That issue with Debian is precisely something I want to avoid when working for KDE and Kubuntu.

The reason why I started the patch in Kubuntu instead of upstream is because of the circumstances at that time. First, Kubuntu will be using D3lphin by default in Kubuntu 7.10, which is about a month away. So time is of the essence. I needed to get this patch done, tested, and uploaded ASAP. Second reason would be a lower entry barrier. If I were to submit the patch to both Kubuntu developers and to Marchel Junke at the same time, I bet that the patch would get tested and incorporated quicker in Kubuntu. And again, the time factor played an important part in that. Given more time, I would most probably have communicated with D3lphin developers first. Who wouldn’t want their work (or name) to reach more people, anyway?

@Eike: thank you for your concern. Both KDE and Kubuntu are special to me. You know me and how committed I am to creating an amicable working relationship. I am committed to not cutting out either end of the development stream. I do want to get my patch upstream. But after this, I’m a bit wary of how to proceed. Will he/they eat me?

But I also wonder if all changes should always be pushed or started upstream. What if upstream refuses to accept those patches or new features? What if other downstreams (of the same upstream) do not want/need those changes? Perhaps it’s a case to case basis. Some patches would probably be of interest to upstream and the general whole, while some would most probably be of interest only to a specific downstream. Perhaps implementing some patches on the distro level first also has advantages. Patches would get used and tested first by more users, allowing upstream to observe the changes. Think of it as testing it on guinea pigs and weeding out the bad patches.

>> The point is that there is a need and an incentive for different parties who use and distribute an open source product to convene in a central space for development, to avoid fragmentation, to keep quality up, to make sure that improvements are broadly available to all end-users.

This one I absolutely agree on. But maybe saying feature-level development should only be in upstream isn’t really the solution. Isn’t this the sort of technical and social centralization that Linus is essentially trying to overcome (re: git discussion in core-devel)? Instead of a central space for development, how about a central place for communication? I do understand, though, that distros shouldn’t just keep to themselves. But I guess upstream shouldn’t always expect or demand that development should start or happen on their turf alone, or that things will always go their way. The road goes both ways IMHO. And I will try hard to wear both hats responsibly. Of course presuming I get to wear either hat in the first place.

If there’s anything that all these has made me realize, it’s that a common place of communication is needed, something I thought about in my other post about upstream and downstream. But perhaps I’m to idealistic. The utopian dreams of the young.

It means that development should happen within the organization created for that purpose, i.e. upstream, where parties with varied agendas convene to assemble a balanced, useful piece of software on neutral ground where they can help out each other and share their improvement to everyone’s collective benefit.

As I wrote in my earlier post, it’s perfectly legitimate for a distribution project to employ developers to work on functionality they feel is important for their target demographic and then contribute it to the upstream project. The obvious example is the Linux kernel, where the majority of the (non-driver) code is being written by developers who are on the payroll of a distribution, but it’s submitted to the Linux community for discussion and integration.

Whenever this hasn’t been done, however, i.e. when distributions have kept kernel features out of the mainline and away from the wider community, their quality has suffered massively from the lack of testing and review, and the distributions have had to put in extra work to keep their additions working with mainline, because they aren’t pulled along by the community. Kubuntu has suffered from similar problems as you know.

A distribution-affiliated developer has two simultaneously wear both hats: He’s a member both of the upstream project and the downstream distribution, and has to responsibly balance out the interests of both. The better distributions have an active interest in making sure that it is as easy as possible for the developers they sponsor to function as a member of the upstream projects, because it gets them better results (and thus people will think of themselves as Kernel developers and not Red Hat developers).

> Does it mean that downstream devs are incapable of creating “feature-level” modifications?

Incapable in so much as they do not have the means to ensure quality, and are likely to turn their development enterprise into an uphill battle as the wider community becomes less and less likely to want to help them out in a bind because they keep development to themselves rather than share it for the benefit of everyone (and no, “but anyone who wants it can grab it from somewhere on our website” does not work).

> I have always thought, perhaps wrongly or too ideally, that unlike a real river, development in FOSS flows both downstream and upstream. Perhaps I was wrong?

The point is that there is a need and an incentive for different parties who use and distribute an open source product to convene in a central space for development, to avoid fragmentation, to keep quality up, to make sure that improvements are broadly available to all end-users. Imagine a KDE world where every distribution kept to themselves rather than contribute to kde.org: The more fragmentation, the harder it gets to support end-users, the harder it gets for application developers to target the platform, the harder it gets to make any forward progress because of the lack of pooled manpower.

I have attended Kubuntu development meetings in the past for various reasons, and have encountered a worrying amount of project members who do not understand that dynamic, who treat upstream projects not as the shared spaces they are, but as wall-socket code supply that occassionally drops some more code into their lap via some mysterious process, and then the distribution gets to do all the important work. Who actively jump at including half-baked patches as differenciation factor from other distributions, and have no interest in bringing those modifications up to speed and actively sharing them with the wider community of the component they apply to.

If I seem unseemingly critical of you right now, it’s because I’m concerned that as a new open source contributor who is loyal to the first project he made a connection with you might be adversely influenced by a work ethic and mindset that does not reflect the real strengths of the open source model.

Incapable or limited is a matter of perspective. Any distro can indeed create feature-level modifications if they so choses to. The question is whether that is always appropriate given their resources. The resources may be time, the number of developers, or how well they understand the code they are adding modifications too. The upstream developers likely know the code a lot better, and may therefore produce a patch or modification of better quality.

And no, I don’t think all feature development should start from upstream. Their time is not always enough to do it, and they may suffer from blind spots that end users and/or distro makers do not suffer from. But there is no need to learn to package stuff to get a patch into the upstream source either. That is going about things the wrong way if you ask me, and this ties in into things going both up and downstream.

If you as an individual hacker modifies something, don’t package a new modified version. Create a patch-file and get it to the upstream developers. If it’s good enough and doesn’t break things you may not see, it could be incorporated into the next release. At that point, it would trickle down downstream again to the benefit of everyone and just the Kubuntu/Fedora/whatever users.

Packaging it would make sure that your contributions would (mostly) only be suitable for your distro of choice and its derivatives. Sending the source back upstream does not. Besides, if the patch is not incorporated in the main source you would most likely have to reapply the patch(es) whenever the next version is released upstream.

So yes, development goes both ways. At least ideally, but not always.

A while back there was a good deal of bad blood in the Debian community regarding Ubuntu, because they felt that Ubuuntu was free-loading on the Debian infrastructure and good-will while not sending their patches back upstream as much as they should have. Well, that was the Debian take on the story at least. I didn’t pay enough attention to know how true that point of view is. Still, doing ones utmost to avoid such sentiments to arise in the first place is always good whether it is true or not in that specific instance.