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

还没有读者喜欢这个。
Organizations coming together like a puzzle

Opensource.com

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

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

慕尼黑市是另一个值得关注的案例;他们成功完成了 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 具有尽可能强大的上游关注点,因此添加新功能始终着眼于更大的图景。因此,实际上 Kolab 现在在后台支持完整的语义交叉项目关系,并且正在不断改进。

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

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

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

标签
User profile image.
Georg Greve 是 Kolab Systems 的联合创始人兼首席执行官,Kolab Systems 是一家完全开源的群件 ISV。他已经在该行业工作了一段时间,并专注于软件自由和开放标准。之前的努力包括为 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 也可能通过在桌面上运行 Windows 虚拟机而“原生”于 Linux。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 方面做得更好(以 postfix 为例)。

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

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

特别是由于每个人的需求往往略有不同。并且理解每个安装的个别需求并准确设置所有组件(例如目录服务),以满足该安装的期望仍然是一项专家任务,有时会花费大量时间和精力,具体取决于要求的具体性或特殊性。

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

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

您可以花费时间来培养技能、解决自己的问题,并用您的时间和知识做出贡献。或者,您可以使那些花费了时间并构建了解决方案的人能够进一步推进它,以造福您自己和所有人。

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

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

但是,强大的力量伴随着巨大的责任,包括尊重他人专业时间的责任。

回复 作者:alana mercant(未验证)

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