Funny, Scoble and I were talking about this very issue when he was interviewing me yesterday.

We're definitely talking to the Longhorn team, and they have access to all of the designs and code behind this prototype.

But part of building the kind of relationship with a product group that enables tech transfer is to understand how to respect the roles of the research team and the product team. In the end, the decision about what ships in the product is the product team's
alone. They have a very difficult job balancing out features vs. risk vs. schedule vs. stability, and they are the experts at that -- researchers aren't. In MSR we completely defer to them, and we also defer on the timetable for announcing which features and
technologies are in or out of the product. There are a set of decisions that they need the flexibility to revisit late in the game if necessary, and announcing too much too early takes away that flexibility.

That's a very long-winded way of saying "I can't say" because it's neither my decision nor my place to speak to it.

A big part of educating researchers comes down to teaching them about the product cycle. Take the same research team with the same brilliant idea, and have them go talk to the same product team. If they meet during the planning stage of a
product, they'll be welcomed with open arms. If they meet one month from release, when everyone on the product team is concerned with driving down bug counts and hitting the target date, they'll be lucky to even have their meeting requests accepted. Same
idea, same people, very different outcomes.

A big part of educating researchers comes down to teaching them about the product cycle. Take the same research team with the same brilliant idea, and have them go talk to the same product team. If they meet during the planning stage of a
product, they'll be welcomed with open arms. If they meet one month from release, when everyone on the product team is concerned with driving down bug counts and hitting the target date, they'll be lucky to even have their meeting requests accepted. Same
idea, same people, very different outcomes.

It depends who initiates the conversation. If the researchers do, they'll be told to go away.

On rare occasions, a product gorup will come to us and say "our alpha testing is showing that X feature is missing, or if it just did Y then it would really be a killer product. Can you help us figure out whether that's possible?" And we do our best.

Remember that the researchers are all shareholders too, and they equally want to see the product ship on time with great features and great quality. Once we help them to understand the development cycle, they gneerally respect it.

Alphas come pretty darned late in the game, planning is usually long done by then.

But that depends on the team. Some teams are making changes up until literally 2 or 3 months before the release (UI teams tend to do this as the usability feedback from releases comes in).

There's not enough room in the schedule for big new features, but minor ones (UI tweaks) happen up until the documentation freezes, again, as usability feedback comes in.

Other teams freeze their feature set well before alpha - that's when you'll get laughed out of the room.

Right now, Longhorn's in the middle of a rescope (that's been very publicly announced, like
here), so if there are compelling scenarios, things COULD be reconsidered. But not if they negatively affect the overall schedule. Mostly, the teams that make up the Longhorn release
are looking for things to CUT from the plan, not to add in. There's already too much stuff in Longhorn.

Shining Arcanine wrote:
What happens if they talk during the Alpha stage?

Typically, they'll likely be laughed out of the room.

Alphas come pretty darned late in the game, planning is usually long done by then.

But that depends on the team. Some teams are making changes up until literally 2 or 3 months before the release (UI teams tend to do this as the usability feedback from releases comes in).

There's not enough room in the schedule for big new features, but minor ones (UI tweaks) happen up until the documentation freezes, again, as usability feedback comes in.

Other teams freeze their feature set well before alpha - that's when you'll get laughed out of the room.

Right now, Longhorn's in the middle of a rescope (that's been very publicly announced, like
here), so if there are compelling scenarios, things COULD be reconsidered. But not if they negatively affect the overall schedule. Mostly, the teams that make up the Longhorn release are looking for things to CUT from the plan, not to add in. There's
already too much stuff in Longhorn.

So... Jonathan and Kevin are 100% spot on. It might be, it might not.

I think I'll edit the wiki to mention that Longhorn is lacking in Digital Photo Management.

You ought to indicate why you feel that the current digital photo experience isn't good enough btw, that helps (it really does). What features is it lacking, that kind of things.

Also one thing to keep in mind is that digital media is a core part of the longhorn experience, so people are spending a lot of time trying to figure out how to get it right, that helps the chances of getting innovative cool things related to digital media into
the product (otherwise I wouldn't be doing what I'm doing right now (not typing this note, what I do at Microsoft right now) )