<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Marc Laporte coming to town</title>
	<atom:link href="http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/feed/" rel="self" type="application/rss+xml" />
	<link>http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/</link>
	<description>David Tenser&#039;s brand new microblog</description>
	<lastBuildDate>Fri, 18 May 2012 02:14:38 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Thomas</title>
		<link>http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/comment-page-1/#comment-51480</link>
		<dc:creator>Thomas</dc:creator>
		<pubDate>Mon, 14 Sep 2009 21:34:40 +0000</pubDate>
		<guid isPermaLink="false">http://djst.org/blog/?p=480#comment-51480</guid>
		<description>Hi,
if it&#039;s possible to make a tikiwiki &quot;SUMO productization suite&quot; (an enhanced tikiwiki with some &quot;modules&quot; or something else to get SUMO as it is) then I would wish to do Plan A. Forking is waste of resources and migration - what could it do for SUMO?</description>
		<content:encoded><![CDATA[<p>Hi,<br />
if it&#8217;s possible to make a tikiwiki &#8220;SUMO productization suite&#8221; (an enhanced tikiwiki with some &#8220;modules&#8221; or something else to get SUMO as it is) then I would wish to do Plan A. Forking is waste of resources and migration &#8211; what could it do for SUMO?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Majken "Lucy" Connor</title>
		<link>http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/comment-page-1/#comment-51105</link>
		<dc:creator>Majken "Lucy" Connor</dc:creator>
		<pubDate>Tue, 25 Aug 2009 22:58:10 +0000</pubDate>
		<guid isPermaLink="false">http://djst.org/blog/?p=480#comment-51105</guid>
		<description>Well, I&#039;m not sure if anyone is familiar with drupal *and* tiki, for example, who might be able to provide some insight as to which product is &quot;superior&quot;

I think what it really comes down to is whether Mozilla would prefer a more modular product, like drupal or deki, or if we prefer the tiki philosophy, which has the trade off of knowing every feature we use will be compatible with the new version.

Forking is almost inevitable, especially with the idea of productization.  I think Tiki gives the highest chance of not needing to fork (or at least not having to maintain forks indefinitely), the issue with tiki is working out the development process so that everything is included upstream in the next release.  If we go with something like drupal, chances are high that we&#039;d end up maintaining our own modules, which is what&#039;s happening for SFx.

In terms of user experience, any software we choose has the capability to have the same features, with the same layout and same design. IMO this decision is really one for webdev, esp if all options are open.</description>
		<content:encoded><![CDATA[<p>Well, I&#8217;m not sure if anyone is familiar with drupal *and* tiki, for example, who might be able to provide some insight as to which product is &#8220;superior&#8221;</p>
<p>I think what it really comes down to is whether Mozilla would prefer a more modular product, like drupal or deki, or if we prefer the tiki philosophy, which has the trade off of knowing every feature we use will be compatible with the new version.</p>
<p>Forking is almost inevitable, especially with the idea of productization.  I think Tiki gives the highest chance of not needing to fork (or at least not having to maintain forks indefinitely), the issue with tiki is working out the development process so that everything is included upstream in the next release.  If we go with something like drupal, chances are high that we&#8217;d end up maintaining our own modules, which is what&#8217;s happening for SFx.</p>
<p>In terms of user experience, any software we choose has the capability to have the same features, with the same layout and same design. IMO this decision is really one for webdev, esp if all options are open.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

