<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>zarro boogs found &#187; Labs</title>
	<atom:link href="http://snarkfest.net/blog/tag/labs/feed/" rel="self" type="application/rss+xml" />
	<link>http://snarkfest.net/blog</link>
	<description>Fun and games with the politics of open source</description>
	<lastBuildDate>Mon, 16 May 2011 21:34:20 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>The value of planning ahead</title>
		<link>http://snarkfest.net/blog/2010/02/03/the-value-of-planning-ahead/</link>
		<comments>http://snarkfest.net/blog/2010/02/03/the-value-of-planning-ahead/#comments</comments>
		<pubDate>Wed, 03 Feb 2010 15:28:27 +0000</pubDate>
		<dc:creator>mconnor</dc:creator>
				<category><![CDATA[blog]]></category>
		<category><![CDATA[Labs]]></category>
		<category><![CDATA[Software Design]]></category>

		<guid isPermaLink="false">http://steelgryphon.com/blog/?p=127</guid>
		<description><![CDATA[As I ride the subway to and from the Mozilla office in Toronto, around the halfway point I pass over the Don Valley, on the lower level of the Prince Edward Viaduct. The bridge was designed and built between 1912 and 1918, and despite significant opposition on cost reasons, the designer and the commissioner of [...]]]></description>
			<content:encoded><![CDATA[<p>As I ride the subway to and from the Mozilla office in Toronto, around the halfway point I pass over the Don Valley, on the lower level of the <a href="http://en.wikipedia.org/wiki/Prince_Edward_Viaduct">Prince Edward Viaduct</a>. The bridge was designed and built between 1912 and 1918, and despite significant opposition on cost reasons, the designer and the commissioner of public works were able to ensure the lower deck was included for future subway use, despite Toronto not having a subway at the time.  In fact, it would be over 40 years after construction started before Toronto had a subway at all, and over 50 before the Bloor-Danforth line opened in 1966 using the viaduct&#8217;s subway level.</p>
<p>The lesson that hits home every day is that while we should always think about the present when designing something, we should also keep an eye on the long view, and take the short-term costs where the long term savings warrant.  Software development timescales are not the same as subway lines and bridges, and it doesn&#8217;t always pay to take the long view, but we should always be conscious of what we&#8217;re trading off.  We especially need to be aware of this in Labs, as we have to balance the competing desires of going faster and getting features into products.  It&#8217;s not easy, and we won&#8217;t always make the right bets, but we should always try.</p>
]]></content:encoded>
			<wfw:commentRss>http://snarkfest.net/blog/2010/02/03/the-value-of-planning-ahead/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Firefox.next and Mozilla Labs</title>
		<link>http://snarkfest.net/blog/2009/02/05/firefoxnext-and-mozilla-labs/</link>
		<comments>http://snarkfest.net/blog/2009/02/05/firefoxnext-and-mozilla-labs/#comments</comments>
		<pubDate>Thu, 05 Feb 2009 11:53:13 +0000</pubDate>
		<dc:creator>mconnor</dc:creator>
				<category><![CDATA[blog]]></category>
		<category><![CDATA[Firefox]]></category>
		<category><![CDATA[Labs]]></category>

		<guid isPermaLink="false">http://steelgryphon.com/blog/?p=116</guid>
		<description><![CDATA[One of the things I&#8217;ve been doing for the last month or two has been working with my colleagues at Mozilla Labs to figure out how best to start incorporating what we learn from Labs experiments into our core products. The technology transfer problem is well known to the tech industry, but it is fairly [...]]]></description>
			<content:encoded><![CDATA[<p>One of the things I&#8217;ve been doing for the last month or two has been working with my colleagues at Mozilla Labs to figure out how best to start incorporating what we learn from Labs experiments into our core products. The technology transfer problem is well known to the tech industry, but it is fairly new to Mozilla, and as our focus is not on profiting from our research, the solution we need will probably be somewhat different.  One key aspect to acknowledge is that most of the Firefox project history has been more direct and iterative, rather than purely exploratory and R&amp;D-like, within the core project.  We have taken some baby steps in terms of prototyping a few features as extensions, and the extension community itself has provided a lot of inspiration and some features and code, but that&#8217;s generally been a bit of an outsider&#8217;s space.</p>
<p>With the formation of Mozilla Labs, we&#8217;ve been better able to try things that we couldn&#8217;t really explore as part of our normal ship process.  That&#8217;s been great to see, especially as we have explored new and compelling features and interaction models, but now we need to figure out the right way of bringing the best pieces of these projects to all of our users.  Learning how to integrate R&amp;D with the rest of our development process is going to take time and effort, but the goal is to establish a repeatable and transparent process that we can continue to use as we grow Mozilla Labs and the various Mozilla products.</p>
<p>This of course doesn&#8217;t mean we&#8217;ll take something from every project, or even that every project has to result in a core feature to be successful.  The primary goal of Labs is to explore and innovate and try things.  Sometimes that will be successful, other times it won&#8217;t.  Sometimes we will learn things that inspire a different approach entirely, and that is an important success state.  But when we create something compelling, we need to be prepared to learn lessons and adopt the best pieces in ways that make sense.</p>
<p>As our first pass, we have decided to focus on incorporating some aspects of three projects in particular: <a title="Prism" href="http://labs.mozilla.com/projects/prism/">Prism</a>, <a title="Personas" href="http://labs.mozilla.com/projects/firefox-personas/">Personas</a>, and <a title="Ubiquity" href="http://labs.mozilla.com/projects/ubiquity/">Ubiquity</a>.  The key defining characteristic of these three projects is that we&#8217;ve spent enough time exploring those spaces that we feel confident in identifying and uplifting the most useful pieces.  Users should expect to see these new features in the next Firefox release after 3.1.</p>
<p>Some preliminary work has been done on identifying key elements of all three projects, and we will continue to refine these plans in order to get a good jump on things as Firefox 3.1 finishes.  You can find these first passes here:</p>
<p><a href="https://wiki.mozilla.org/User:Mconnor/PersonasUplift">Personas</a><br />
<a title="Ubiquity Uplift" href="https://wiki.mozilla.org/User:Blur/UbiquityUplift">Ubiquity</a><br />
<a title="Prism Uplift Draft" href="https://wiki.mozilla.org/User:Mconnor/PrismUplift">Prism</a></p>
<p>We absolutely crave feedback, so please feel free comment here, send mail or comment on the Talk pages on the wiki if you have questions or concerns.  We hope to get to a crisper and more tightly-scoped set of plans over the next month or so, and we&#8217;ll continue to point out when there are more changes that we&#8217;d like feedback on.</p>
]]></content:encoded>
			<wfw:commentRss>http://snarkfest.net/blog/2009/02/05/firefoxnext-and-mozilla-labs/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

