玛伊琳·达菲

我非常相信开源设计的可能性，并为此做了很多傻事来捍卫它。也许我对“开源”和“设计”的定义不同。

然而，问题实际上不是开放与不开放，而是有多开放 - 不是吗？正如 Chris 和 Burney 所指出的，即使在设计公司内部，也存在开放程度的谱系。为了本文讨论的目的，如果存在二分法，也许可以算作“开源”的是“像大多数开源代码项目一样开放”（因此仅在组织内部不算数。）

你指的是“开源”在所遵循的流程方面，还是所产生资产的字面许可方面？（你甚至可以像我一样疯狂，考虑所涉及工具链的可用性，例如，是否使用了免费的开源工具？但我很疯狂 :) ）无论如何，过程和许可都很重要。例如，《Sita Sings the Blues》是一位艺术家的作品，但它是开源许可的。但是等一下。妮娜·佩利并没有创作或演唱安妮特·汉肖的那些歌曲（实际上，她现在正因一些版权胡说八道而陷入困境） - 她也没有创作《罗摩衍那》 - 那么这真的算作一个个人项目吗？它也更接近光谱的“个人”一端，但是...（沃尔特·迪斯尼创作了《白雪公主》或他借用的格林兄弟童话中的任何一个吗？但我现在正在窃取莱西格的经典论点......）据我所知，她也没有遵循开放流程，因为她是独自工作的。（我可能错了。）

一段软件不是设计吗？在开源软件中，有一些非常棒的体验，有些是公司大力赞助的，有些则不是，在这些软件中，设计/实现都是公开进行的。Firefox 可能就是一个很好的例子，我认为 Inkscape 也是另一个例子；我相信你能想到其他的例子。但这是对你问题的显而易见的答案。

如果不是软件，那么 3D 电影呢？这些算吗？
http://www.bigbuckbunny.org/
http://www.elephantsdream.org/
http://durian.blender.org/

Durian 项目尚未完成。但是，如果你查看他们的网站，你可以看到他们在博客上记录他们的设计过程，并公开征集参与。是的，公开征集参与。我的朋友 Chris Webber 实际上建议团队进行一次开放的“建模”冲刺，Durian 团队在其中发布了他们需要创建的模型列表，并安排了时间和“地点”（在线），供人们前来帮忙。正如你所看到的，它取得了成功

http://durian.blender.org/news/community-modeling-sprint/
http://durian.blender.org/news/modeling-sprint-a-stellar-success/

“天哪，伙计们。我星期六下午来的时候，惊讶地发现维基上的几乎每一项都有名字，并且有将近 200 人登录了 IRC！”

多好的机会啊。一个与经验丰富的专业人士合作的机会。我愿意付出一切来获得这个机会 - 甚至在我还是一个充满时间和热情的高中生时就能拥有 Blender！想想一个无法（无论是经济能力还是其他原因，我相信你很清楚）进入艺术学校的孩子 - 这是向专业人士学习的好方法。使用不会让你的家庭花费任何费用的专业级工具......

与《Sita》形成对比，《Sita》主要是由一位女性完成的个人秀，采用开源许可，但使用闭源工具，而 Durian 项目是一个多人核心团队，他们协作工作，并在物理位置上共同定位，使用开源工具，并在开源许可下发布他们的源文件和最终作品，并且偶尔邀请社区成员参与工作。并且定期通过公开访问的博客记录所有工作。因此，我认为 Durian 项目在“开放设计”光谱中与《Sita》处于相反的端点 - 很多人，很多沟通，外部社区参与，以及开源许可。

对于这里的另一种可能性 - 针对以封闭/专有许可证授权的事物采用开放/透明的设计流程，我没有例子可以给你。我不确定这在开放性方面与《Sita》相比如何，但我倾向于认为它更开放。

不喜欢电影/不喜欢这些例子？那么 http://www.thingiverse.com/ 怎么样？他们有人们设计实物，在开源许可（CC 在那里很流行）下共享 CAD 文件，并在开源 3D 打印机上打印出来。看看，他们有一个 pingback 系统，如果有人采用另一个设计并对其进行改进，就会被记录下来（例如，看看这个 http://www.thingiverse.com/thing:2035）

这与 openclipart.org 和 openfontlibrary.org 的模型类似……但 Thingiverse 是实物！:) 他们在 Thingiverse 上创建了 iPod 或 iPhone 吗？没有。所以也许不是带有“D”的设计。虽然老实说，我认为 MakerBot 本身就是带有 D 的设计，就它引发的文化运动以及它运行良好的事实而言......

iPhone 或 iPod 真的那么伟大吗？我两者都没有，但即便如此，我仍然感受到其设计和存在的次要影响，所以也许它很伟大。我知道这是一个不公平的问题，但是在人们拥有 iPhone 之前，他们拥有的所有手机都发生了什么？垃圾填埋场？毒害第三世界国家一些儿童的饮用水？如果所有这些手机制造商实际上都共享了他们手机的设计信息，并从彼此的错误中吸取教训，而不是在过去十年左右的时间里推出不太有用的手机设计（硬件和软件），那会怎么样？我相信在此期间有设计师参与其中，那么为什么在 iPhone 之前有那么多手机“失败”了呢？在商业方面，有些事情是足够好就足够长一段时间了（不一定是个人感觉，而是企业/公司的整体感觉/行为），直到其他人足够关心将其做得比足够好更好。然后竞争升到另一个层次，因为突然间有了理由（例如 Apple）。

我认为可能有一个区别，如果你不是为了赚钱而做生意，如果你是为了热爱而做生意，那么足够好也是不够的。我认为很多自由/开源软件的人都是为了热爱而做这件事 - 他们只是通常不是设计师。这种情况会改变吗？如果改变了，会产生影响吗？当开源项目“竞争”时会发生什么？（Chromium？）如果你真的热爱某件事，你想公开设计它吗？（我想，我认为这增加了让很棒的想法融入其中的机会。也许有些人不同意，他们想保护它免受外界的影响。）

有时，设计的艰苦工作是对最终真正无关紧要的事情做出决定。我认为开源设计的弱点是，在这些类型的决策上，通常会发生大量的绞尽脑汁 - 突然间，人们的注意力从重要的事情上转移到关于徽标应该是蓝色还是绿色的争论上。（Seth Nickell 最近在 GNOME UX Hackfest 上提到了一些事情，请参阅此处的最后一段，尽管我认为帖子的其余部分有点极端：http://blogs.gnome.org/seth/2010/02/23/i-did-the-worst-design-of-my-life-within-gnome/）因此，iUniverse 在这方面具有优势，因为（我假设）可以做出这些决定，并且人们可以被转移到更有趣/更重要的决策，也许是通过指挥链的组织，或者开源社区中不可能存在的其他机制。

设计在开源社区中是如何运作的？你不能仅仅用“因为我说了算”或“因为我是设计师”来为设计决策辩护。这行不通。“因为我们共同同意我将对项目的这一部分负责，我们必须继续做更酷的事情”是可以的，（尽管如果与一个有充分理由的，即使不是普遍同意的理由相结合，那就更好了，例如选择 A 给我们带来了这个优点），它在开源社区中确实行得通。我认为能够说“我负责，我们继续前进吧”对于开源设计的实现和社区的健康都是必要的。（“因为我说了算”的态度是不健康的，我认为：无论是否是开源社区！）

我认为，也许开源设计在有健全的参与结构的地方蓬勃发展。例如 Durian 征集建模参与的呼吁。或者我们在 Fedora 设计团队中发起的参与呼吁。如果有人主动担任项目组织者，举办黑客马拉松或举办活动，或记录需要做什么以及如何做（例如 Durian 需要的模型维基），他们就会构建一个框架，在这个框架内更容易参与。对于代码来说，也许更容易 - 嘿，它可以编译，它可以运行，它可以做我想做的事情。但是对于设计，人们会害怕他们不是设计师，他们不够好，他们要说的话并不重要……我认为，如果有某种形式或结构让他们理解应该发生什么，就更容易克服这一点。框架本身就是设计吗？我不总是这么认为。有时框架会做出很大的设计假设，这些假设绝对是设计的关键部分，但设计是它所具有的有机过程（对吗？），有时框架的设计假设会被颠倒过来，最终结果会更好，而框架同样实现了设计。

我最近一直在思考的事情之一是，我们在开源项目中沟通的方式并没有为设计创造一个健康的框架。有趣的是，正在进行一些项目，其中一个项目可能在今年夏天成为 Google Summer of Code 项目，以尝试补救这种情况，这些项目正在公开设计。:)

也许这是一个奇怪的问题，但是 - 在工业化前的世界中有什么东西是设计的吗？那些东西是以封闭的方式设计的吗？人们不是分享信息并一起工作吗？我的意思是，这个问题听起来很幼稚，我很确定，但是过去人们不是合作建造城镇、教堂和学校吗？我相信设计和销售设计的东西可以追溯到很久以前，但是一直以来销售的是设计还是材料和生产成本？是工业化和大规模生产在某种程度上赋予了设计更多的价值，不是吗？我一直在思考诸如多年来流传下来并不断改进的特定编织图案和绗缝图案……哎，甚至食谱和烹饪方法……这算作开源设计吗？

一个奇怪的例子，但是山地自行车是开源设计吗（你读过它们是如何产生的吗）？

还有一件事 - 付费或无偿在一些评论中被提及，我认为这无关紧要。如果有人是付费的，他们与无偿的人一样有能力以开源方式进行设计。实际上，他们可能更有能力，因为他们有足够的时间来正确地完成它。

最后，我们需要更多设计师参与开源。看来我们也可能需要在设计师中更多地采用开源？

希望这些漫谈对您有所帮助。

嗨，Chris！

只是一个快速的反驳 - 我确实看到人们在谈论设计视角与工程视角，以及哪个更重要。但我认为在很多情况下，重要的不是设计或工程 - 而是业务。例如，避免因产品过于不同而导致推出失败产品的风险。

我认为在很多情况下，工程师也出于业务需求/决策的考虑，推出了他们宁愿不推出的东西……

~m