Especially Bo idea about devoting more time to hand-holding people in bugzilla is IMO a great thing to do. I try to do it from time to time, sometimes it takes little more than one sentence, but I certainly only do it once in a while, and it would be great to emphasize that on a larger scale.

/be

http://tinyurl.com/2rmtzh

15 out of 74 are still NEW (none are UNCONFIRMED or ASSIGNED):

http://tinyurl.com/2jum9y

Some low-numbered bugs show ball-dropping by Netscapers, long gone. The bugs have not been touched in a while, generally. If any of these patches is still needed, then we need owners to act accordingly. I will follow up.

In more than a few of the more recent bugs, where the patch manager was around to help request review, I see a failure by Jon and others who might do it to set the r? flag to name a peer or owner, causing that person to get email.

Yes, the owner and peer should review incoming bugs and jump on any that get patches, where the r? flag wasn’t set (I and others do this for JS engine bugs; yay for us, as we non-NIH our way to Tamarin integration).

But mistakes happen, and the patch submitter has to be vigilant too. We probably don’t want bugzilla’s attachment UI to force or default r? flag setting.

On the general “NIH” claim, Mozilla is hardly immune but also far from convicted. We use other code, rewrite over time to get rid of our own old baggage, navel-gaze over Webkit, etc. etc. To use the “NIH” acronym carelessly, especially when downstreams are not only busy with their own products, but venture-funded and conflicted enough to use license poison pills — this careless charge (I think that’s what it is, I’m giving benefit of doubt — it could be something more like malicious) frankly stinks, IMHO.

Mozilla has code review requirements, and we aren’t going to drop those. We’ve added unit test requirements, sort of (reviewers and others require them or just know to do the work). We aren’t going to lower these barriers to entry.

Who is doing what, Mozilla jargon, how to work the system if you run into a lack of respose — these are all things to work on, and it’s great to see Reed credited with helping. IRC is important to our working culture, maybe too important, but if it ain’t broke… Anyway, this is not the first time we’ve had complaints about getting patches in, and as usual, when I dig into particulars, there are recurrent low-level problems on “Mozilla’s” side *and* on patch submitters.

Mostly these problems seem to be background loss of owner attention, sometimes due to silent loss of owner. I’m talking about the Mozilla side. Patch attachers may simply not know to set r? to an owner or peer bugzilla id. There’s probably no technological fix, but there could be better bugzilla UI.

Patching before collaborating on design is another problem. No project wants that cart before the design horse; it sucks to have to reset a complex, possibly useful (in part) patch to the design review stage it missed. Design review means using the newsgroups as well as IRC, the wiki, even blogs — and of course bugs, but with design docs before code patches.

I see more design collaboration over time, not less, in spite of Ian’s complaints, and I agree with roc that cdouble’s work on video was more than open enough for others not to throw NIH stones. Chris is in town this week, so if Songbird folk want to host something, or make the trip down to Mt. View, I bet he’d be up for it.

/be

I too am curious what specific instances you have where Mozilla asked Flock to re-license something and that didn’t happen. The only request I’m aware of was for the tagging UI widgets, which is the recent one you referred to in your post. Since I’m not aware of any other requests, I’m wondering where communication broke down here, because any request I would have heard of I’d have tried to make happen.

Any change we make to base platform code we try to push upstream, whether they be bug fixes or enhancements. The only exceptions are some quick hacks that we want to refactor or get rid of anyway, nothing that would be acceptable upstream.

@Schrep
I think part of the problem here is that Mozilla doesn’t necessarily pay much attention what’s going on downstream, so this comes across as NIH. Given how much legwork it takes to even get comments on potential ideas in Bugzilla, it’s hard to justify time to push new features upstream, especially considering that Mozilla’s rather conservative attitude regarding adding core features would mean a high rejection rate.

So any changes to upstream code should be pushed upstream, that’s a no-brainer, and we at Flock certainly have been doing that. This has a clear benefit to both organizations. Contributing back wholly new features is another matter, and it’s unclear how to make this work smoother.

Lilly and I Visited Flock several years ago in person to talk specifically about sharing code. MConnor and I personally visited Joost in their offices in the Netherlands after last Fosdem for exactly the same reasons. I’ve talked personally with the Songbird folks many times. I can continue to cite others. In all cases I believe the core issue is that these folks are busy trying to ship their own products and getting code committed back to Mozilla is *a lot* of work. We can and should make it easier for folks to contribute – but I reject the assertion that it is NIH on either side of the fence here.

It’s pretty possible that you have a problem with it because I didn’t mean it. I believe that Mozilla should care about helping other people/organizations contribute to Mozilla, because their contribution can be extremely worth it.
Additionally, I believe that Mozilla should grew a separate model of treating external contributors who are a members of Mozilla based project differently from an external private individual volunteer who wants to start contributing. And the reason for that is because those two kinds of contributors are totally different. Driven by different motivators, satisfiers, pushes and pulls. That’s all what I meant. It’s not about other people products. (Although I disagree with you that it’s not in Mozilla business to make sure that the environment is broader than our products). It’s about what we do to let others contribute, and do we encourage them and help them, or just we make sure there are no major blockers. Two attitudes, two visions and two different results.

All the stuff around the licensing is known, and is unfortunate. We’ll be stuck with the GPL for a while, and it’s a license that’s not good for end-user products, believe it or not. It might be good for developers, depending on your state of mind. Having to triple license Mozilla was unfortunate, it enabled things like songbird and other stuff with virally licensed libs, but it does make getting stuff back upstream hard.

So yes, finding out what it takes to land a patch is hard. Hell, I don’t know our reviewing rules these days. Which tells you that landing patches in Mozilla is hard. Not that it has something to do with “invented here” versus elsewhere. Note at the side, using RDF bugs as examples in this context just makes your argument lame. Not because it’s my module, but because you know that RDF will get nuked independent of what we do to it, so there’s no effort to improve it.

The biggest problem I have with your post, though, is that you make it sound like MoCo should care about other people shipping their products, instead of shipping its own.

And that, as utopian nice as it’d be, is just not the right thing to do.

That said, MDC is much better than what we had when you started, and I guess that anybody could just go ahead and invite shaver over for a lecture on how to contribute some company’s code back upstream, or just join a devday whish spread across the globe. There is the Evangelism team. Yeah, right, the Evangelism team, a whole devision at moco that only cares about our ecosystem.

So, while the actual problems you describe are there, and happen too often, your analysis doesn’t fit. It’s neither “NIH”, nor is it something MoCo isn’t working on.

I think it might not be a terrible time to have a regular Mozilla contributor or two set aside some amount of time for developer outreach and hand-holding. They would help contributors do “first bugs,” review patches for proper coding style so they’re ready for the actual review (which would ideally be done in a timely manner).
I’ve seen this happen in a few bugs, but I think explicitly dedicating time to the task and advertising the program would be very useful.