Zope 宣传檄文汇集 ::-- ZoomQuiet [2005-08-11 10:39:52]

1. Zope访谈

对话Zope 系列!

ChinaZope - Pan Jun Yong

#pragma section-numbers off 回到Zope 宣传檄文汇集 ::-- ZoomQuiet [2005-08-31 10:29:36]

潘老大是如何上了plone的船的?引发

  • 回答一部分先....

1) 还是先介绍一下我自己吧 ;-)

本科和研究生的学位其实都是机械,研究生阶段从事产品数据管理方面(PDM)的研究,这个倒和内容管理颇有接近;99年毕业到上海中兴通讯,从事过一段时间GSM软件测试工作;后来有一段时间JSP的web开发经历;再后来,也做过数据仓库方面的一些大型的开发和应用。

a. 潘兄和zope/plone 的關係(如何時開始使用, 原因等)
2:你什么时候在什么情况下知道Zope的?

我对开源一直是很感兴趣的,但是知道zope其实很无意;当时在研究工作流引擎方面的产品,先研究过offbiz等java项目,发现系统无比复杂,全部要靠配置文件操作;后来找到了openflow这个zope上的产品,后来又找到了zope;

Zope的ZMI让我耳目一新,从前JSP上如此复杂的操作、功能,在Zope上可轻松实现。然后看到Zope公司那些巨型的案例,以及zope.org上无数的产品,后来有发现CMF,这才知道:自己要做的大部分事情zope这个平台都已经替你完成了。后来看到Plone,知道有人把你最不拿手的界面问题都解决了,这个时候,我就觉定投入到这个产品中。

(补充一下,我是在开始zope编程的时候,才开始python的,limodou、杜工当时都是我崇拜的对象,现在也是)

2:你什么时候编写了什么Zope 的应用?

是最早的模块,是CJKSplitter,大概在2002年10月左右就完成了。当时发现Zope最大的障碍是不支持中文搜索。虽然台湾有人做了一个模块,但是使用配置非常麻烦,而且在windows上好像还不太能用,也不支持简体。这时候我就写了一个CJKSplitter,其实当时对Zope还根本不太熟悉
;-)

算的上一个应用的,是我们公司现在rpAnalyzer的前身,另外一个ZMI版本的分析器,用于分析一个CRM系统的数据,大约是2003年1月左右完成的吧。

3:你什么时候什么情况下知道Plone 的?

在研究CMF的时候,发现一个skin计划,顺着找过去,发现“性感”的Plone站在那里,一下子就给迷倒了;-)
当时还根本没有CMF的文档,可怜我当时的辛苦,Plone也只有0.9版本,Plone的文档也非常少。

好在我看代码的能力比较强,这都是当年在中兴测试软件的时候练出来的;-)

Plone Soutions - Alexander Limi

Plone创始人Limi的采访

Contents

先翻译一段,准备陆续翻译完,limi对社区的做了非常大的贡献。他的言论,对CZUG的构建和发展也非常有好处。-- PanJunYong

问1:你是谁?

我是Alexander Limi,挪威Plone Soutions公司的首席架构和交互设计师。教育背景是心理学和计算机科学。

问2:你和Plone以及Plone项目的关系是什么?什么时候,你是如何进入Plone的?

2002年我和Alan Runyan在Texas Houston开始这个项目。我现在在项目中的角色是用户界面设计,项目管理和社区沟通协调。同时,我是Plone Solutions公司的一员,这是我的一个公司,我的朋友、一些Plone开发人员也在其中。我全职做Plone相关的工作,虽然我偶然也被雇佣去做纯粹的用户界面和交互设计。

问3:你任务Plone作为一个机会速最出色的地方是什么?

Plone在一个非常灵活的软件栈之上构建,我们可以快速地改造以满足新的一些机会,或者实现新的想法。Plone在这个过程中是很轻量级的,实现某个功能,让他成为核心框架的一部分是很容易的,只需要让其他人认同让这个组件进入系统。

另外一个主要的部分是,我们有强力的多语言支持。目前Plone支持超过50种翻译,拥有唯一的超强的处理国际化和本地化的方法,以及在多种语言中维护内容的方法。这使得我们在类似欧洲的市场中处于前列,那里多种语言的支持几乎是必要的,但同时也开始影响传统只有一种语言的市场,比如美国。西班牙语作为第二语言的兴起,让很多公司正式寻找那些能够处理超过一种语言的软件。

有趣的是,我任务Plone作为一个技术最强壮的地方是,他大部分的价值在Plone的愿景、目标和解决挑战的方式。Plone最积极的观点,实际上是技术并不那么重要,这不是因为技术而技术。如果Plone将全部底层切换为另外的什么东西,它仍然是Plone,她仍然是一个拥有强大愿景和方向的强大社区。选择这个技术,是因为她在开始最可能解决我们的问题,但是作为一个社区,我们非常灵活。我们可以调整底层技术来解决我们的问题。这是Plone和她的社区最积极的东西:她的多样性和灵活度。我坚定相信这个态度影响了这个软件和参与的人员。

问4:Plone最大的问题,或者威胁是什么?

如大多数开源项目一样,文档是一个最大的困扰。引入新的Plone开发人员应该可以变得更加流畅些,但由于相对比较大的软件栈的使用,这也更加困难。web开发是一个复杂的工作,使用web进行内容管理则更是。但,这个在去年已经进步了许多,已经出现了使用多种语言发行(英语、德语、日语)的4本书,还有更多会出现。

至于威胁,现在最大的威胁不是技术问题,而是市场和注意力的斗争。好在,我们在众多的优秀系统中脱颖而出,每次发布,人们都开始关注我们。有趣的是,现在开始看到Plone开始不断在不以Plone为中心的各种文章中出现,说Plone已经被用于X或Y,或者说是"在商业领域一个可用的系统"。尽管如此,我们在这方面还有很多事情要做。

我坚信Plone下一个大的挑战是市场 / 注意力/ 讲解 领域,这是我个人最近大量时间和精力的花费所在。

问5:你对Plone社区的感觉如何(如:强/弱、紧密/分散,大/小,等)?在Plone的开发中,社区的重要性如何?

Plone社区现在达到了非常多人的阶段。这表示,既便他的某些领导者一段时间不太参与,这个项目也不会停滞;而且,现在有足够多的公司完全依托Plone来做生意,不管某些人或者公司出现什么问题,他们都需要让这个项目保持活跃。

问6:你感觉是社区的一部分吗?社区对你自己对Plone的行为影响多大。

社区很影响我的行为。不断的反馈,过滤和监视Plone用户和开发人员邮件列表,对推进Plone和解决人们实际面临的问题和挑战非常重要。这个社区是Plone。

问7:Plone从一开始就已经是开放源代码了,当时是如何做出这个决定的?

这是理想主义和商业敏感的一个融合。我们都相信软件是一个商品,它也可能变成负资产。也就是说如果人们没法继续贡献,最终它就一钱不值。软件需要不断的构建和优化框架来解决你的新调整,你需要人解决这些问题,来帮助你走出困境。一旦某个公司破产,他们的软件就消失了,因为他是封闭源代码的和私有的。真正的价值来自对产品的优化、不断的测试和改进,这些能够再次帮你的客户解决问题。这是价值链中非常重要的一环。如果软件带来的问题比它解决的还要多,它就不好了;对于自主版权的软件总是很容易陷入前面的这种类型,尤其是对于这类软件来说。

从商业角度来说,这也是唯一可以接受的方式。一小群人,凭借自己的力量,完全没有办法和你那些类似Vignette, Interwoven or Documentum 的庞然大物作战。因此,你使用开放源代码做为一个竞争优势。对于公司中使用的内容管理系统这样关键的东西,开放系统是唯一的长期可行的解决方案;

内容管理系统的市场天生就是机能不全的:当你从供应商那里作为一个自主版权的产品,你才仅仅走了一半。你需要和你自己的现有系统、你的工作流、你的业务过程进行集成。你为什么要为这个仅仅一个公司才能做的特权支付?如果你的供应商改变了业务方向,或者破产,将会发生什么情况?你还能让你的系统正常运行吗?你还能扩展它,让它和你不断变化的业务适应吗?

问8:使用Plone构建他们的解决方案,是类似Plone Solutions这样公司的特殊商业模式中明确的一部分吗?

其实更多是另外一方面 (原文:It was more the other way around ) - Plone Solutions是基于兼容软件开放源代码途径的商业模式构建,而且基于相同的核心价值构建。这就是说,Plone社区真正漂亮的东西是:他非常关注商业。大多数严肃的Plone开发人员来自全职开发Plone的公司,并以之为主要的、或者甚至唯一的收入来源。想法,也有很多开发人员,他们是纯学术的或者是学生,他们是整个Plone生态中扮演重要的角色。他们通常有很多有趣的想法,而且有时间来实现他们。

我相信,商业和理想主义的这个结合,能够让Plone社区成功 - 他们在不同的方向一起拉动,但是因为只需进行必要的沟通和协调就可满足双方的的需求,你可以得到一个非常柔性和强大的、有众多竞争力的工具。

How much of a help or hindrance is Plone's license when you sell Plone-based solutions?

问9:当你出售基于Plone的解决方案的时候,Plone的许可证有多大的帮助或者障碍?

对我们自己,而不是所有人,这决定于你所在的市场 - 有些市场(比如欧洲)对开放源代码非常接受,其他的市场(比如美国的)则更多是怀疑的,需要更多的说服工作。当然,这是一般的情况,会有很多具体的商业因素。比如:航空工业对开放源代码会更严格,但政府会更加接受。我们非常幸运,我们总能获得比我们想做的更多的工作机会,而且能够高兴的找到有趣和有益的客户,他们帮助构建Plone和他的内部结构,而不是为了生存而对我们的理想进行妥协。

Many would consider the team of "limi & runyaga" Plone's spiritual leaders, if you will. Yet, while you have been very active and vocal on the mailing lists and chat room, Alan has been quite silent, both on the lists and in the codebase in the time leading up to the 2.1 release. Do you agree with this assessment? Do you feel that there is a leadership vacuum on the technical side, or is the community sufficiently strong to manage by itself?

问10:很多人认为,"limi &runyaga"是社区的精神领袖。然而,当你非常活跃,在邮件列表和聊天室经常发言的时候,Alan无论是在邮件列表、还是在发布2.1版的代码库中,通常非常安静。你同意这个说法吗?你是否觉得在技术方面有一个领导真空,或者社区是否强壮到有能力自我管理?

真空有时候是有益的:你在专注平衡一方的时候,不会被其他因素影响。尤其是,接下来的这个版本已经看到,大量的和重要的更新是和用户使用习惯相关的,尤其是你在你坐下来第一次开始使用Plone的时候;他给我们时间来优化和重写一些核心组件,而不是不断发明新的内部结构 - 这对作为一个产品的Plone非常重要。

当然,你不可能永远处于那个状态,我们有明确的认识:技术和用户界面两方面相同重要。社区认识到了这个,在一定程度上(当另一方实现很多时)能够自我修复。如果技术方开始落后很多,社区就会开始提出问题。如果技术,我们会选择某人来领导技术决策。幸运的是,我们不必到这个程度才开始做这些,你可很容易看到社区的这个自修复机制正在工作。

我预计Plone最近将进入更多功能扩展和内部优化的阶段 新一代的优化界面需求已经开始驱动内部结构的提升了。当前的阶段修改了很多用户界面的基础问题,我们准备开始进入下一个功能级别,一起来将优化用户体验,以和新增加的强大功能相匹配。

有趣的是,既便增加功能和优化结构上耗费了大量资源,我们还是很奢侈:我们能够让很多没有实现的可能可通过底层的细小优化和一些用户界面工作而不被锁定。用户界面方面最重要的事情是:优化、优化、优化。总是有很多事情可以做得更好,大多数情况下演变比革命要更好-既便通常后者要来得更诱人。

回到最初的问题,我完全相信社区达到必要时能自我组织的阶段。在这条线上,有足够的资金和商业机会,他能够让公司在这个开发过程中开始投入资金。当然,人民希望原始的团队领导能够提供远景和指导,但他们不再需要做所有的工作,象他们从前那样。

我主要看到我现在的角色是提供远景和组织社区,以拉向某个方向。通常很难脱离实际的开放工作,因为有时候这个需要什么的远景已经非常细和明确了,以至于诱使你自己正确完成他。将工作委托给其他人来说,是社区成长的一部分,我坚定相信Plone正在朝这个方面正确迁移。这个过程很痛苦,但是最终会受益颇丰。

问11:领导Plone社区、回答邮件、解决争论的时候,你的主动性积极性如何?做这些事情的重要性如何?该谁来负责?

答:我现在非常活跃... 社区是我们最重要的财富:现在社区拥有这么多的牛人,为Plone做了那么多难以置信的事情,但是当初只是一小群人。

更多的人应该参与进来。但目前我很难保持沉默。一个人不可能参与各方各面。我想,作为一个社区,一个团队单元,这类似婴儿的成长,逐步的放开让他自己去走。让他自己去认识各种事情。

和其他社区不同的是,Plone社区有非常多的面对面交流机会。我们组织工作室、会议和非正式的聚会,大多数人在社区拥有很多亲密的朋友。通过这个途径,我们可以对Plone相关的东西进行非常深度的讨论,而且很少出现不愉快,因为他们很有可能彼此相互见面,然后知道他是一个人,一个不错的家伙。这是将"在讨论什么"与"谁在参与"的一个不错分离,而且这促就了一个健康的社区。我们能够成为生活中的好朋友,而且能够在具体的实现细节上兴奋的争论,同时,我们不会冒犯任何人。

问12:你对Plone社区的构成有何感想?商业驱动占多少,志愿者驱动又占多少?是否某个更加重要?公司的兴趣和志愿者的兴趣,二者是否能和谐统一?

这是一个很漂亮的、平滑的分裂。Plone拥有非常强的商业兴趣,但有同样强的志愿者工作。前面说过,这个结合构成了Plone社区,者也是Plone能够成功,但其他很多项目失败了的原因。我们从不在某个方向走太远,我们专注,但同时在无数的方向。我们在专业领域拥有惊人数量的知识,我们拥有众多通才和架构师。这是非常健康的构成,而且我们社区拥有健康的对话。

问13:很多开源项目在核心拥有非常大的理想主义,比如相信软件一个免费和共享。Plone是否完全被这些意识形态影响,或者Plone的哲学理念更实际?

好,我们回到社区的健康分裂。参与的人,包括很多理想主义者,以及很多关注商业的人。对这些问题有一个很有趣的途径,我们必须在决策的时候保证双方都能够接受。很多人以Plone谋生,其他则以之为乐趣。总的来说,我相信我们属于更新、更成熟、和兼容商业的开发源代码。我们不害怕商业和使用我们的产品赚钱。但同时,在这个过程中,我们保留一些核心价值,既便他可能让我们失去一两个合同,但是我们回家睡觉醒来的时候,我们会对自己以及我们每天做的工作感觉良好。

就这些了。把握你自己的命运,用自我满足的方式工作,一个可靠的产品,而且非常多有趣的、让人惊奇的人。


扩展讨论

  • 大家可以继续抒发哦

Zope CTO - Jim Fulton

Jim Fulton(Zope公司首席技术官)访谈录 Document Actions

回到Zope 宣传檄文汇集::-- ZoomQuiet [2005-08-25 03:09:17]

1.1. Jim Fulton

这是Zopera team做的Jim Fulton的访谈。问题是从Zope的法语社区收集的。Jim回答了Zope的起源和未来,还有Zope公司和Zope的商业模式。
Jim Fulton(Zope公司首席技术官)访谈录
  • 原作:Publié le 15/02/2002 par
  • 翻译:alang,于2005/08/25
  • 来源:http://www.zopera.org/Members/odeckmyn/fulton_iv_2002/view

    1. Zopera Team (ZT) : 你是什么时候发现Python的 ?
      • Jim Fulton (JF) : 1994
    2. ZT : 你什么时候决定要使用它?
      • JF : 1994.那时我正在为Rand公司的Walter Hobbs用Per实现的一个/rdb数据库而工作。它有一个基于Perl的、使用Perl解释器的数据库操纵语言。我努力的让它可以为美国地质勘探局/ 美国地理学会?(USGS,US Geological Survey)的科学们工作。那些人觉得Perl的语法太怪异了,并且Perl的自动把字符串当作一个数字的问题,给数据分析带来了许多麻烦。我正在寻找 一个轻量级的、面向对象的语言,让我可以操纵数据。我找到了Python。 
    3. ZT : 你是什么时候决定增强/升级它的?(我们的google狂人们只找到了至1994年之后的信息)
      • JF :我猜第一次真正的增强,是虚对象API(abstract-object API),是我和Guido在1995年做的。我写了一个Python扩展来访问Ingres数据库,并且正在开始做一个工具,它能自动生成访问 Fortran库函数的(Python)扩展。Python的C API非常cool,但是用它,让写一个非常灵活的给它传递数据的扩展的工作变得太难了。
    4. ZT : 这听起来好象你曾经做过SmallTalk程序员?(Smalltalk,一种“古老”的面象对象语言--alang注)

      • JF :是的,Smalltalk太cool了。我用GNU Smalltalk给USGS的家伙们写了一个可视化的图表编辑器。我另外花了一点时间在ANSI Smalltalk委员会上。那儿似乎到现在还有一些有条不紊的工作在进行,尤其是Squeak。(Squeak是Xerox PARC实验室的Alan Kay大牛人--可惜今年被HP给裁员了--发起的一个基于新的Smalltalk-80标准的一个开放源码的新的语言。alang注)
    5. ZT :那时让你有了这个想法,用SamllTalk来写Zope。是真的吗?

      • JM : No. :)

    6. ZT : 为什么你最终选择了Python?
      • JM : 那个时候我已经成了Python的皈依者了。 ;)

    7. ZT :如果今天再来让你选择,你会选择Python,或者会试着用SmaallTalk(用squeak或者GNU SmallTalk)吗?

      • JF :我很确信,我还是会选择Python。有很多理由:
        • Python的语法更清晰易懂
        • 多重继承。当有多重继承的时候,它会使多个框架的协同工作更简便,途径更多。
          • 这儿还有许多其它的理由,在1996年的时候我就考虑不再使用