这家自由软件公司能否确保慕尼黑市 Linux 的未来?

还没有读者喜欢这篇文章。
Organizations coming together like a puzzle

Opensource.com

开源领域已经解决了许多问题。但群件并非其中之一。

否则,您如何解释平均而言在群件中失败的迁移数量?瑞士州索洛图恩只是众多例子之一,原因是群件供应商已经放弃并转而使用 Outlook 或网络来满足他们的需求。 Kolab 的做法有所不同。首先,Outlook 永远不会成为 Linux 桌面的客户端。而且,网络对于很多事情来说是一个很好的答案,但并非所有事情都是如此。

慕尼黑市是另一个值得关注的好案例;他们成功完成了 Linux 迁移,为他们节省了数百万欧元。但是现在,新当选的市长和他的副市长通过公开考虑迁移回 Windows 而登上了新闻。为了进一步探讨这个问题,我们首先暂时忽略市议会需要批准任何战略变更,并且已经重申了对 LiMux 的承诺。我们也忽略了城市员工不认为回到 Windows 是一个好主意的事实。

那么,是什么促使LiMux 成为新闻中质疑的对象呢?

如果您猜测 Office 互操作性可能与此有关,那么您就猜对了。只要存在相互竞争的标准,占主导地位的供应商与市场上的其他参与者之间就会存在不兼容性。文档交换仍然是一个持续存在的问题,最终只能在政治层面解决。这个特殊的问题不是技术性的,英国最近已经证明,他们将选择开放文档作为标准格式来解决这个问题。 

他们对 LiMux 的使用的另一个主要批评是缺乏集成的群件系统。直到今天,慕尼黑市仍在继续使用完全在 Windows 上运行时使用的独立日历和电子邮件系统。当时,更新这些系统的优先级低于迁移到 LiMux。但是现在升级正在进行中。而且,他们选择的解决方案与桌面平台无关,将同时为 LiMux 和 Windows 提供服务。另一次迁移造成的主要差异很可能归因于任何迁移带来的风险,例如额外的成本和延误。

换句话说:用于批评 LiMux 桌面的问题实际上已经被解决了。由 Kolab 提供,这与德国联邦信息技术安全局 (BSI) 10 多年来使用的协作解决方案相同。它特别的优势是什么?以安全、可扩展和受控的方式为高度异构的环境提供服务的能力。作为市场上唯一一款为 Windows *和* Linux 提供真正原生客户端的群件解决方案,它可以为跨平台用户提供一致性。并且它的 Web 客户端非常用户友好且功能强大,以至于其独立的 Webmail 组件 Roundcube 是世界上最受欢迎的 Web 邮件应用程序,在全球拥有超过 50 万次安装。Mac OS X 应用程序的原生连接对于慕尼黑市来说不太重要。但是,其强大的移动电话集成正是市长可以理解地期望从现代安装中获得的功能。

当然,解决方案的工作永远不会完成。最近的 Kolab.org 3.3 版本 特别关注了可用性。我们还必须考虑如何简化从旧日历系统到用户概念的过渡,旧日历系统的用户概念几乎与今天的应用程序截然相反。虽然现代系统在很大程度上是基于电子邮件和邀请的,但旧系统并不“邀请”人们。它将事件添加到他们的日历中作为公开邀请。电子邮件在这方面几乎不起作用,并且实际上没有与系统集成。更有趣的是,旧系统塑造了用户的期望和模式。例如,每个用户都可以查看任何其他用户的日历的默认策略。而且,虽然以前只有部分用户拥有日历,但将来所有用户都将拥有日历。因此,我们讨论的是 40,000 到 120,000 个共享日历的范围,具体取决于用户的设置方式。

这绝不是一个容易解决的场景,而是一个有趣的挑战。我们遇到过一些安装,在这些安装中,尽管计算资源几乎无限,但 Microsoft Exchange 还是失败了,最终被 Kolab 取代。但是这些安装的共享文件夹比慕尼黑市少。幸运的是,Kolab 的架构支持这些要求。但是,使其可用并尽可能少地打破现有的用户习惯和模式是完全不同的事情。因此,我们从根本上改变了用户导航日历的方式,使其采用用户应该熟悉的流程。它最终基于会话内的快速搜索和跨会话定期访问的日历的收藏夹。并且因为我们喜欢一致性,Kolab 现在将该逻辑应用于所有群件数据。

为了方便过渡,Kolab 团队还在日历中添加了打开和拒绝的事件的视图,以及通过允许更新传播的策略、组织策略的实施(关于谁可以邀请谁)以及资源管理领域的一系列改进,在后台进行了大量自动化。现在可以邀请非唯一资源并从池中的第一个可用资源获得确认——因为您可能不在意分配给您的是四个相同的投影仪中的哪一个,只要您有一个用于演示文稿即可。资源现在还获得了其特定的邀请对话框,其中包含一个资源查找器,可让您查看资源的日历。

其中许多功能长期以来一直存在于慕尼黑市用户的愿望清单中。新系统将结合一种方法,该方法既保护习惯和用户模式,又提供新的、长期以来渴望的功能和更大的灵活性。例如,能够将备注附加到电子邮件 和通过标签对其进行排序。或者,一个完整的任务工作流程,包括分配和基于电子邮件的委派和接受。并且由于 Kolab Systems 具有尽可能强大的上游重点,因此添加新功能始终着眼于更大的Picture。因此,实际上,Kolab 现在在后台支持完整的语义跨项目关系,并且正在不断努力进行进一步改进。

日历改进带来了迄今为止最强大的功能之一,即日历快速视图。当快速搜索用户时,只需单击一个按钮,即可打开一个专用视图,该视图将显示该用户已同意向您提供的所有内容。无论他们的内部文件夹结构如何,无论他们的访问控制列表 (ACL) 如何,您都将看到您有权看到的内容。在您无权查看详细信息的地方,您将获得合并的空闲/忙碌视图。这非常以用户为中心的方法,与通用空闲/忙碌系统完美互补。

如前所述,慕尼黑市仍然为某些应用程序保留了旧的 Windows PC,这些 PC 可以充分利用 Web 客户端。但是,所有这些新功能也通过基于 KDE PIM 的 Kolab 桌面客户端提供。该客户端将可用于即将发布的 LiMux 版本以及 Windows。因此,除了 Web 客户端之外,所有城市员工都将拥有一个一致的应用程序来满足他们所有的群件需求。

因此,无论慕尼黑市决定继续走 LiMux 成功的道路,还是再次尝试 Windows 的运气,群件问题都将得到解决。Kolab 将在任何一种情况下都发挥作用。这可能正是说服 LiMux 的所有用户的决定性因素。因为一旦痛苦消失,替罪羊的需求也就消失了。

标签
User profile image.
Georg Greve 是 Kolab Systems 的联合创始人兼首席执行官,Kolab Systems 是一家完全开源的群件独立软件供应商。他在该行业工作了一段时间,非常关注软件自由和开放标准。之前的努力包括为 Google 从事 OOXML 标准化流程、撰写 Brave GNU World 以及在 2001 年至 2009 年期间创立并主持 FSFE。

7 条评论

很棒的帖子!解决不兼容性问题的关键是决定标准:标准文档格式、标准流程等。然后找到一个可以接受可用格式的工具,用户可以访问这些格式,直到整个组织完全转换并标准化为决定的格式。例如,LibreOffice 可以读取大多数 Microsoft Office 格式以及开放格式。是的,有些例外情况,某些 Excel 或 VBA 格式可能无法转换。但是,如果这些文档转换为 PDF,Linux 用户将能够查看它们。不是群件专家,所以很高兴您启发了我们什么是可行的。

附注。(请删除我对这篇文章的第一条评论。)

作为市场上唯一一款为 Windows 和 Linux 提供真正原生客户端的群件解决方案...只是想指出 IBM Notes 客户端在 Windows、Linux 和 Mac 上运行,除了电子邮件和日历之外,还提供应用程序开发。

Java 客户端是 Java 堆栈的原生客户端,而不是底层平台的原生客户端。这带来了所有的安全隐患。

回复 作者 JohnInPA (未验证)

那是把不需要复杂化的事情复杂化了;无论是否是 Java,Lotus 都是适用于 Windows/Linux/Mac 的多平台。没有人做这种区分(例如,称之为“Python 堆栈原生”)。同样,php(Roundcube 使用的)并不比 Java 更安全。只是想在这里公平一点 :)

回复 作者 greve

Java 是一个完整的虚拟环境,很像虚拟机。多平台不一定与平台原生相同。如果要遵循这种逻辑,Outlook 也可能是 Linux 的“原生”客户端,因为它是在桌面上运行的 Windows 虚拟机。而且 Lotus 不是 Java 环境原生的唯一解决方案。

至于安全性:Java 或 PHP 中只有一种导致了 91% 的所有入侵指标。提示:不是 PHP。

http://www.eweek.com/security/java-primary-cause-of-91-percent-of-attac…

因为虽然 PHP 允许糟糕的程序员编写非常不安全的应用程序,但该语言本身提供的攻击面比 Java 小得多。

回复 作者 localdevjs (未验证)

一篇有趣的文章,如果不是因为我们在 Kolab 上遇到了一些非常糟糕的混乱,包括不久前在 IRC 上被 jvm 斥责,因为我们不理解非常复杂(但有其原因)的 LDAP 实现。我们得到的最终答案是:“对不起,如果你想做得好,你必须付费,不会向你解释所有内容”。不太友好,虽然它是开源的,我们都在一定程度上怀有理想地工作(虽然我完全理解人们需要谋生),但礼貌和合作不是坏事。结果,我们不得不抛弃所有 Kolab,因为这种态度根本不受欢迎。通过巧妙地使开源产品变得如此复杂,唯一的出路是聘请作者,这也不是真正的开源。这是最近一些公司做得有点过分的巧妙营销。
遗憾的是它本可以成为一个好产品,但这种态度完全毁了我们,只是我们的看法,也许其他人会更幸运。

听到你显然选择回到专有世界,我感到抱歉。

这些年来,我们多次遇到对免费咨询和支持的期望,因此我们的技术团队可能没有像您期望的那样礼貌地解释说,通过忽视他们的任务而优先在专门用于开发者之间协调的 IRC 上回答用户问题,这对所有为 Kolab 的开发做出贡献和支持的用户和客户来说都是极其不公平的。

此外,群件是一个复杂的问题。

如果您想要一个通用的解决方案,该解决方案不会将您锁定在特定的技术路径中,也不会限制您的能力,那么一定程度的复杂性是您付出的代价。这就是为什么我们投入了大量精力来为那些具有必要基本技能和教育背景的人提供关于各个标准系统组件的文档,而没有复制他们的个体文档,因为我们认为我们不能也不应该在记录 postfix(以一个例子为例)方面做得比 postfix 团队本身更好。

对于那些具有更随意的工程背景的人,我们创建了一个简化的设置,其中包含一组明智的默认选择,供那些只想快速运行的人使用。最重要的是,我们正在与发行版合作,以获得更好的上游打包,并简化各种平台管理模块上的安装。

因此,确实花费了大量精力来降低复杂性,尽管我们意识到,这种努力永远不足以让 100% 的人设置和运行自己的服务器。

特别是由于每个人的要求往往略有不同。并且理解每个安装的个体要求,并设置所有组件(例如目录服务),完全按照该安装所需的方式进行仍然是一项专家任务,有时会花费大量时间和精力,具体取决于要求的具体或特殊程度。

虽然我们更愿意把时间花在帮助所有用户和客户的事情上,但我们很乐意帮助个体用户和客户解决他们的问题。

但如此花费的时间将无法用于其他任何事情,包括为所有其他用户改进解决方案。因此,这样的时间需要付费,以确保多数人不会为不愿遵守与其他人相同规则的少数人付出代价。

您可以花时间培养技能,解决自己的问题,并用您的时间和知识做出贡献。或者,您可以让那些花时间构建解决方案的人进一步推进它,为了您和所有其他人的利益。

这比任何专有解决方案都能给您更多的选择。

这是自由软件/开源赋予人们力量的方式之一。

但是,权力越大,责任越大,包括尊重他人专业时间的责任。

回复 作者 alana mercant (未验证)

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.