Shared publicly  - 
Changing +Ubuntu's development process to be more closed is one thing, but pretending to open it up and claiming it's more open than +Red Hat is a completely different story.

Everything Red Hat does is developed and tested in #Fedora first. It needs to follow our feature process, that means it needs a wiki page and will be discussed in public before it gets approved or rejected by the Fedora Engineering Steering Committee, which is elected by all Fedora contributors, the vast majority of them being community members.
Take +systemd for example, one of the biggest changes we had in the last years. systemd was in fact held back by FESCo for one release because it was in a state that did not convince us.
And now, let's have a look at Ubuntu and one of it's features that got a lot of attention recently: The shopping lens. If the blueprints are Ubuntu's counterpart to Fedora's feature process, why can I not find a blueprint for the shopping lens anywhere? Who approved the lens? How could the community influence this decision? Where can I track the decision making process?
Does anybody still think Ubuntu's development model is "far more open and trusting" than Fedora's?
Jeremy Bicha's profile photoJef “Credible Hulk” Spaleta's profile photovlada m's profile photoChristoph Wickert's profile photo
Well, for now, i only thank Canonical about Ubuntu for using Debian now. And thank Crunchbang developers for migrating the default access from Ubuntu to Debian! (Crunchbang is maybe the best way for installing Debian)
Then again, Ubuntu being that wee bit more popular is also open to more public scrutiny than Fedora does. Their popularity is pretty much their own downfall. 
Well sometimes Red Hat just seems to do it's thing, too. Like exchanging maintainers of packages I'm co-maintainer on without notice (i.e. by following correct Fedora procedure).
My instinctive reaction was to look for Jeff "Watchdog" Spaleta's response.
+Felix Kaechele I agree that sometimes some people in RH do not behave right, but we (as in Fedora and it's bodies) try to make them follow the rules. Think of the mass ownership of the perl modules which was revoked by FESCo.
Even if individuals sometimes do bad, the overall process in Fedora is way more open and transparent. Nobody can rush something into Fedora without approval, it's very much unlike the "tadaa" moments Mark blogged about.
Mark pretty much stated that he doesn't care if people don't like this approach. What it does is create a two-tiered "community" though.

My initial thought was that these people will be like unpaid contractors. And even though Mark said they wouldn't need to sign an NDA, they will still be expected to not talk about things, and they'll still need to sign Canonical's contributor agreement.

Canonical will do what they do, though. I'm not going to worry too much about it. 
The comparison to Red Hat and Fedora is a sideshow, and its a classic retorical device to misdirect discussion away from examining the core issue of contributor relations. 

Whether or not Ubuntu or Fedora is the more open "project" and whether or not Canonical or Red Hat are the more open "companies" is an emotional hook to encourage "tribalism" as Mark previously termed it.  He wants to set up an us versus them dynamic, to encourage his own constituency to more readily accept Canonical's management philosphy as an open philosphy.  He needs as large an emotional response from both inside and outside the Ubuntu community, because when people are reacting emotionally.. they are not thinking rationally..and criticism born from emotional responses are more easily deflected and turned aside.

I look forward to seeing what the first couple of externals selected  to work as unpaid contractors under Canonical's direction have to say after they've gone through the process in the next 6 month cycle.

+Jef Spaleta - the tribalism and knee jerk emotional reactions extends way beyond the current topic at hand all the way to how we as a society approach most things. Not discussed often enough. Most folks are either content to think in this knee jerk way or to manipulate those that do. is the feature freeze exception bug for the shopping lens. It needed to be signed off by the Documentation Team (which is basically 100% non-Canonical), the Translation Team (where dpm is the only Canonical guy I'm aware of on the team), and the Release Team. The Release Team had full power to accept or reject the feature since it was after Feature Freeze. While most members of the Release Team are Canonical employees, not all are.

The idea of requiring blueprints for features is interesting, but it depends on how you look at it. A Red Hat employee could get a new feature into GNOME (say, like redesigning Nautilus) without a Fedora blueprint and perhaps without even following GNOME's feature proposal process. If you think of Unity and the lenses as a separate upstream (which confusingly enough, is how Canonical views it), then it's not so different than what Fedora does. Unity features do get tracking bugs in Launchpad and it's not clear that duplicating that information to a separate blueprint would make things better.
+Jeremy Bicha Thanks for the background info.
Of course a Red Hat developer who works on +GNOME can introduce a feature in upstream and this will probably make it appear in Fedora's GNOME, too, because we are very committed to upstream and hardly refuse anything from them. We are way more picky with our distribution specific features, think of #usrmove .
But whatever this developer works on it's still a GNOME feature, it is by no means specific to Fedora or Red Hat. It will go into all other downstream derivatives of GNOME just like it goes into Fedora. Unlike the shopping lens: Canonical is upstream, it will go nowhere because it doesn't serve any purpose outside of +Ubuntu. The only purpose is to generate revenue for Canonical.
If Canonical views it as a separate upstream project, that's simply wrong. The idea was born in Canonical, it was developed (secretly!) in Canonical, it never had a community to back it.

The feature freeze exception bug you linked completely proves Mark wrong. He claimed that decisions about features are made by the developers at UDS. For the shopping lens it was quite different. Quote from the bug:
"This is a sabdfl driven project, apologies for being late."
So do you really think the release team had the power to reject that feature? No, they hadn't, +Iain Lane form the release team made it pretty clear: "Since this is a Mark decision, it doesn't need my approval, ..."

And then Mark claims that the Ubuntu development process is "far more open and trusting than the Red Hat process". Sorry, but he must be kidding us.
Who in Ubuntu decides whether or not a new feature is accepted? How can I track the decision making process? Where can I find the commit history of the project before it suddenly appeared in version 6.0 (!) on the day of Beta 2 freeze and nearly 4 months after feature definition freeze!?
It's also worth noting that in that bug report.. the security audit step was basically punted and failed to catch the unsecured http usage for search terms. If it had not been a rushed and top-down pushed exception, I would expect the security audit to have been more meaningful. 

And the fallback positions communicated in the exception request were not followed. Two reasonable fallback plans were laid out in case the feature hit some gotchas. It hit some gotchas..clearly. Neither a) nor b) were actually followed when it became clear that the code over the wall..both client and server.. needed adjusting.  Where was the communication concerning the decision to not go with the communicated fallback plan?

Everything Canonical employees touched on this request was shortcircuited. Security audit was punted, the release team member side-steps the role of approval/disapproval because Mark was pushing it. All of that is laid out in the bug ticket comments.

The point is... the project lead should show some restraint and not lobby nor force through feature exceptions process. EVER. If your project lead can't get his critical items into place in time to meet the established deadlines to let the process work as expected.. then the process is entirely broken.

If this feature were introduced at UDS the feature inclusion process would have gone much more smoothly instead of being a ticking clock panic attack to get this feature fixed.  Seriously... having the feature land using unencrypted http for the search query transfters is a huge facepalm moment and a huge redflag. That sort of thing is what should be caught when the feature is living as a tech preview in a ppa for the couple of months running up to UDS. There's no good reason for this feature to have skipped the ppa early adopter step.  The whole thing is rushed... god only knows what problems lurk on the server side that no external can see at all or test or fix. Rushed client... rushed server backend... bad for everyone.
vlada m
Shuttleworth promised that the next version will have new features that he calls "some sexy 13.04 surprises".
And having things in the open means you cant do like Apple and have surprises that you can market for maximum coverage.
When something is know months ahead of time, you cant have a special event to present these new sexy features. You dont have the build up, the anticipation, the blog speculation and theories which lead to a climatic finale.
You dont create buzz and cool by being open.
Marketing methods that depend on secrecy means that its more easy to manage responses as it condenses everything in a small time frame.
This isnt about methodology but rather marketing and throughout Shuttleworths response you will find comments like "not wanting to spoil the surprise when we think the piece is ready."
There's that word again: surprise.

I appreciated Spalleta's finely worded first post above so much that I forwarded it to colleagues and everyone to a person agreed with him.
Why is surprising people or being cool so important? Canonical does not compete with Apple or with windows, they compete with Red Hat and SUSE on the enterprise market. None of these two tries to get attention with fancy surprises, instead they deliver something that is very open for enterprise customers: reliability.
I see your point, buzz and transparency don't go together well, but if marketing is more important to Canonical than a solid development process, their approach is fundamentally flawed.
Community skunkworks are still skunkworks and a benevolent dictator is still a dictator.
Add a comment...