Icon Rufen Sie uns an
+49 441.309197-69 +49 441.309197-69
 
DE

Eigenes Fenster anstatt neuer Tabs in der Kopano WebApp / DeskApp

Posted by Jan Schoone on Wednesday, May 31, 2017

Kopano Webseite

Die Kopano DeskApp und natürlich auch die WebApp öffnen neue E-Mails typischerweise in einem neuen Tab – und zwar innerhalb Kopanos. Das kann man als Vorteil sehen, manchmal nervt es aber auch. Zum Beispiel kommt es vor, dass ich beim Beantworten längerer, umfangreicher E-Mails die Original-E-Mail und vielleicht sogar weitere Mails sehen möchte, während ich die Antwort tippe.

Hier hilft der kleine Button, auf den der obige Pfeil zeigt. Das ist die PopOut-Funktion, welche den entsprechenden Tab in einem eigenen Fenster öffnet.

In den Einstellungen unter Mail -> Allgemeine E-Mail-Einstellungen kann man wählen, ob E-Mails standardmäßig in einem „WebApp Reiter“ oder einem neuen „Browserfenster“ geöffnet werden sollen.

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

DE

Mit der Kopano WebApp/DeskApp freie Zeitslots im Kalender finden

Posted by Ingo von Thielau on Monday, May 29, 2017

Kopano Webseite

Es ist immer eine Herausforderung, mehrere Teilnehmer einer Besprechung zusammen zu treiben. Hier hilft die Kopano WebApp mit einer kleinen, fast schon unauffälligen Funktion: Beim Anlegen eines Termins kann man über den Button „Teilnehmer hinzufügen“ Personen auswählen, die teilnehmen sollen. Neben dem eigentlich „Termin“-Tab gibt es dann auch noch einen „Planen“-Tab. Dieser zeigt das obige Bild mit den vermutlich hinlänglich bekannten Frei/Gebucht-Zeiten.

Jetzt kann man natürlich selbst scannen, wann es freie Zeitslots gibt. Oder man lässt es Kopano für sich machen. Der Pfeil zeigt auf eine Liste mit Buttons, die Zeitslots vorschlagen, an denen alle Teilnehmer gleichzeitig verfügbar sind. Diese gibt es pro Tag. Den Tag, an dem es prinzipiell freie Zeitslots gibt, muss man also noch selbst finden.

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

DE

Termine in der Kopano WebApp/DeskApp kopieren

Posted by Behnam Zare on Tuesday, May 16, 2017

Kopano Webseite

In der WebApp (und das alles gilt auch für die DeskApp) können Termine im Kalender schnell und einfach per drag & drop verschoben werden. Was aber ist, wenn ein Termin kopiert werden soll? Das mache ich tatsächlich öfters und es ist wirklich sehr einfach - wenn man weiß wie es geht ;-).

Zunächst muss in der Kalenderansicht der zu kopierende Termin mit einem einfachen Mausklick markiert werden. Ein Rahmen um den Termin zeigt an, dass dieser markiert ist. Rechts oberhalb des Kalenders findet man die beiden kleinen Icons, auf die der rechte Pfeil zeigt. Der Papierkorb beinhaltet genau so wenige Überraschungen wie das daneben stehende Kopiersymbol. Ein Klick darauf öffnet den daneben stehenden Standarddialog. Hier sollte der aktuelle Kalender bereits markiert sein, so dass ein simpler Klick auf Kopieren exakt dasselbe Ereignis neben dem soeben markierten noch einmal anlegt.

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

DE

Shortkeys in der Kopano WebApp/DeskApp aktivieren

Posted by Behnam Zare on Monday, May 15, 2017

Kopano Webseite

Drucken, Löschen, durch E-Mails navigieren und viele weitere Funktionen können in der Kopano Webapp mit Tastenkombinationen ausgelöst werden. Diese sind aber nicht immer aktiv. Das entsprechende Menü steckt in den "Einstellungen" unter "Tastenkombinationen". Hier kann man verschiedene Profile aktivieren. In bestimmten Sprachumgebungen gibt es Konflikte, darum ist manchmal das Basis-Profil eine gute Wahl. Weiter unten im selben Menü findet sich eine Liste aller aktiven Tastenkombinationen.

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

DE

Infrastrukturdatenbank Meilensteinplan 2017

Posted by Daniel Rauer / Felix Kronlage on Tuesday, May 09, 2017

Je mehr Kunden wir die Infrastrukturdatenbank vorstellen und je öfter wir die IDB auf Konferenzen zeigen desto mehr Ideen entstehen welches die nächsten Schritte sein könnten und welche Funktionen von uns und unseren Kunden gewünscht werden. Mit der Veröffentlichung der IDB Kernanwendung sowie ihrer Adapter auf GitHub, unter einer von der OSI anerkannten Lizenz, haben wir letztes Jahr einen grossen Schritt getan: Ein internes Werkzeug zu einer Open Source Lösung zu entwickeln.

Aktuell bewegen wir uns innerhalb der Version 1.6. Die Versionierung und der Entwicklungsablauf der IDB sind einfach: Die Entwicklung passiert auf dem development Branch, aus welchem neue Versionen in einen release Branch herausgelöst werden. Für den 1.6er Zweig werden nunmehr lediglich kritische Fehler behoben; daraus werden bei Bedarf entsprechende Versionen 1.6.4, 1.6.5 usw. gebaut.

Funktionen der IDB Kernanwendung sind an die Version der IDB gebunden; Funktionen die lediglich Adapter betreffen dagegen nicht. Daher haben wir sowohl einen versionsbasierten Meilensteinplan für die Kernwanwendung wie auch für die Adapter. Diese Pläne enthalten alle wichtigen Erweiterungen um einen Eindruck zu vermitteln wohin sich die IDB entwickeln wird; all die kleinen Verbesserungen und Korrekturen sind jedoch nicht enthalten. Die vollständige Liste mit offenen Fehlern und ToDos findet sich auf GitHub.

Meilensteine der Kernanwendung

Version 1.7 - geplante Veröffentlichung Ende Q2 2017

Zwei wesentliche Neuerungen werden in dieser Version enthalten sein:

  • Mandantenfähigkeit
  • Version 3 der API

Mandantenfähigkeit

In der IDB gibt es das Konzept der "Owner", inhaltlich übersetzbar mit "Kunde" oder "Besitzer". Diese sind mit Ressourcen wie Maschinen (physisch wie virtuell), Inventarobjekten etc. verbunden. Die Mandantenfähigkeit schränkt die Sichtbarkeit dieser Objekte auf mit dem Anwender assoziierte "Owner" und deren Objekten ein. Wir werden zeitnah über die technische Umsetzung dessen hier auf unserem Blog berichten.

APIv3

Mit der dritten Version der API werden wir alle Ressourcen sichtbar machen, im Gegensatz zur aktuellen Version 2 die dies nur für Maschinen und Software Pakete ermöglicht. Die kommende Mandantenfähigkeit ist hier sinnvollerweise bereits berücksichtigt um unbefugte Zugriffe auch via API sicher zu verhindern. Das die APIv3 ein wirklich grosser Schritt ist, sieht man an der Liste der Neuerungen die uns mit der Fertigstellung ermöglicht werden:

Durch die Möglichkeit auf das gesamte Datenmodell der IDB zuzugreifen können wir nun sowohl NeDI als auch oxidized integrieren: Dann werden nicht nur Netzwerke und Switche über die API verwaltet, sondern auch Dateien können über die API an Objekte gehängt werden. Dadurch wird ermoeglicht automatisiert Router- und Firewallkonfigurationen in der IDB versioniert zu verwalten.

Ebenfalls wird der Ansible Adapter, von dem im Verlauf des Textes noch die Rede sein wird, auf die APIv3 aufbauen und Teil der Arbeit an der Version 1.7 sein.

Weiterhin werden wir uns dem Thema Reporting annehmen - allerdings wird dies nicht direkt in der Kernanwendung umgesetzt sondern mittels eines Reportingwerkzeugs. Durch die APIv3 sollte es künftig möglich sein Anwendungen wie JasperReports anzukoppeln.

Version 1.8 - geplante Veröffentlichung Ende Q3 2017

Wesentliche Neuerungen dieser Version werden sein:

  • Passwort- bzw. Zugangsdatenverwaltung via Vault
  • neue, anpassbare Übersichtsseite
  • Erwartungsmanagement

Passwort- bzw. Zugangsdatenverwaltung via Vault

Ein integrierter Passwortmanager basierend auf Hashicorp's Vault wird eine der grossen Neuerungen in Version 1.8. Da die IDB Adapter viele verschiedene Informationsquellen durchsuchen, und Zugangsdaten zu u.a. diesen Systemen sicher abgelegt werden sollten, bietet sich der Einsatz von Vault an; ein Passwortverwaltungssystem ist aber in jedem Fall eine Bereicherung für den Anwender.

Übersichtsseite

Aktuell ist die Oberfläche der IDB sehr technisch und wenig ansprechend. Die tabellarischen Ansichten sind für viele Anwendungsfälle hilfreich und ausreichend, aber für eine schnelle Übersicht könnte ein "Dashboard"-ähnliche Ansicht besser geeignet sein. Im Raum steht die Überlegung das Anwender sich eigene Berichtselemente auf einer Startseite einrichten, um wiederkehrende Abfragen und Filter schnell im Zugriff zu haben, beispielsweise die zehn am längsten nicht gewarteten Maschinen.

Erwartungsmanagement

Erwartungsmanagement ist eine Funktion mit der wir Unterschiede zwischen dem Ist- und dem Soll-Zustand einer Ressourcen deutlicher herausstellen wollen. Über die Funktion Netzwerkscans mittels der API in die IDB zu speisen wird es dann möglich sein zu erkennen ob zum Beispiel Netzwerkports geöffnet sind die laut Soll-Definition in der IDB nicht offen sein sollten. Diese Informationen werden ebenfalls über die API abrufbar sein, so dass man hier an ein Monitoringsystem anbinden könnte um bei Soll/Ist Abweichungen alarmieren zu können. Wichtig: Die IDB sammelt Informationen und bereitet sie auf, Alarmierungen wie in diesen Fällen müssen daher über ein Monitoringsystem abgewickelt werden.

Version 2.0 - geplante Veröffentlichung Ende Q4 2017

Auf der Agenda für die Version 2.0 steht "Compliance" als grosses Thema. Wir haben bewusst Entwicklungskapazität zurückgehalten um den Funktionen aus 1.7 und 1.8 den letzten Feinschliff zu verpassen, oder an diesen Veränderungen basierend auf der Erprobung unserer Nutzer im Feld vorzunehmen.

Compliance

Die Kernanwendung speichert bereits aufgrund ihrer Architektur und eingesetzten Werkzeuge Änderungen an Objekten. Wie grossartig wäre es durch den Einsatz von WORM verhindern zu können das ein Objekt nachträglich manipuliert wird. Die Darstellung eines Zustand eines Systems zu einem bestimmten Zeitpunkt sollte in der IDB verlässlich sein in der Hinsicht das sie definitiv und unveränderbar ist.

Planung für die Adapter

Auf diese Adapter werden wir uns in 2017 konzentrieren:

idbiaas

Der idbiaas Adapter sammelt Informationen von diversen Infrastructure-as-a-Service Providern. Begonnen haben wir mit DigitalOcean sowie libvirt-basierenden Umgebungen. Diese werden als nächstes implementiert:

  • OpenStack
  • Amazon AWS
  • CloudStack

Ansible Adapter

Nachdem Ansible durchaus verbreitet im Einsatz ist, und einige unserer Kunden und Partner Interesse an einer Ansible-Unterstützung durch die IDB bekundet haben, kommen wir dem gerne nach und implementieren einen Ansible Adapter. Ein Teil der Arbeit daran wird sein die IDB zu erweitern damit sie als "external node classifier" / "inventory provider" für Ansible dienen kann.

OPSI Adapter

OPSI ist eine Lösung zur Verwaltung von Arbeitsplätzen und hat (als serverseitig Linux-basierte Software) einen starken Fokus auf Windows Desktops. Diese werden zur Zeit nicht optimal von der IDB unterstützt. Der idbad Adapter ist ein Versuch aus Windowsumgebungen mehr Informationen zu gewinnen. OPSI implementiert eine gute REST-API und hält nicht nur Informationen über die Maschinen vor, denn als Softwareverteilungssystem kann auch auf detaillierte Informationen zur eingesetzten Software zugegriffen werden.

PuppetDB Adapter

Die IDB entstand mit einem klaren Blick auf Puppet als primäre Informationsquelle. Daher ist die Informationsgewinnung aus einer PuppetDB aktuell nicht über einen Adapter umgesetzt, sondern als Teil der Kernanwendung. Um sicher zu gehen das alle Informationen über einen zentralen Punkt - die API - eingespielt werden wird die PuppetDB Anbindung künftig ebenfalls über einen eigenen Adapter umgesetzt.

DE

Kopano - Alle Attachments einer E-Mail auf einmal herunterladen

Posted by H. Rasch on Friday, May 05, 2017

Kopano Webseite

Enthält eine E-Mail mehrere Attachments, so müssen diese nicht alle einzeln heruntergeladen werden. Ein Klick auf eines der Attachments mit der rechten Maustaste öffnet das unten zu sehende Kontextmenü.

Click to enlarge

Von hier aus können alle Attachments auf einmal als ZIP-Datei heruntergeladen werden, die sich in eigentlich allen modernen Betriebssystemen direkt im Anschluss wie ein Ordner öffnet. Von hier aus können die Attachments dann per Drag&Drop in die passenden Ordner geschoben werden.

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

EN

Roadmap infrastructure database 2017

Posted by Felix Kronlage on Thursday, April 27, 2017

As we expose more customers to the infrastructure database and present the IDB at conferences more ideas pop up what to do next and what kind of features we - as well as customers - want to see within the product. With the release of the IDB-core as well as the adapters on github under OSI-approved licenses last year, we've accomplished the major milestone for the first year: Make sure that an internal tool becomes an open source solution.

We're currently within the scope of the 1.6 version. The versioning and development scheme of the IDB is fairly simple: We develop on the development branch, this is the default branch for the project, from which new versions are cut on release branches. For the 1.6 line we've reached the point where we will only add bug-fixes that are critical to a customer. That's why there is now a 1.6 branch from which potential 1.6.4, 1.6.5 releases will be made.

While the features of the IDB-core are tied to the main IDB version, features that only concern adapters are not coupled to this. As such, we have a version-based roadmap for IDB-core and a roadmap for the adapters. The roadmap lists all the major features to give you an idea on where we are heading, but it does not cover all the little improvements, bug-fixes and smaller ideas we are working on. For these, please check the issue tracker over at github.

Roadmap of IDB-core

Version 1.7 - to be released at the end of the second quarter 2017.

The 1.7 version will provide two major features that we've been working on this year:

  • Multi-Tenancy
  • The V3 version of the API

Multi-Tenancy

The IDB has the concepts of owners. Owners are associated with ressources like machines, inventory items and such. The multi-tenancy allows to scope the view of users within the IDB to a set of owners. We have a blogpost in the pipeline on how we implemented this.

APIv3

With the third version of the API we want to introduce visibility of all ressources and not just machines and software components. For this to work in a good fashion, we had to make sure that we have scoped visibility first - which is the ground work of the multi-tenancy. From the list of things that the APIv3 will enable us to do, you see that this is one of the major items in the near future:

The APIv3 will allow us to access the complete datamodell of the IDB and opens us to the possiblity to finally add our NeDI as well as oxidized integration, since not only switches and networks can be added via the API as well, we can also attach files to objects in order to store router and firewall configurations.

The Ansible adapter mentioned in the section on adapters further down in this post will rely on the APIv3 and will be part of our work towards version 1.7.

Furthermore we want to look into reporting functionality - however this should not live inside the core application but instead be done by a real reporting tool. With the APIv3 it should be possible to hook software like JasperReports into the IDB for reporting.

Version 1.8 - to be released at the end of the third quarter 2017.

Major items for version 1.8 will be:

  • Password and credential management via Vault
  • Dashboard view with widgets
  • Expectation management

Password and credential management via Vault

An integrated password manager based on Hashicorp's Vault will be one of the major 1.8 features. Since the IDB adapters crawl lots of information sources, and we would want to store arbitrary credentials to ressources in a secure manner, anyways adding a password management for the users is another nice benefit.

Dashboard

The current interface is very technical and and not very appealing. For many tasks the table based UI is helpful, for quick overviews a dashboard-like interface could be very appealing as well. The idea is that users can create their own reporting widgets on the dashboard, for example to always list the ten machines that have the oldest serviced date. Most of the time, I look at the same set of data to begin with anyways.

Expectation management

Expectation management is the feature where we want to highline differences between the expected state of a ressource and the actual state. We will start this feature by adding the possiblity to submit network scans to the API of the IDB, and display whether any network ports are open on a maschine that should not according to the configuration within the idb. The application should then warn about this. Since we expose this kind of information over the API as well, one could even hook this into a monitoring system, that checks the IDB regularly for objects that do not reflect the desired state and alert upon that. Important: the infrastructure database is about aggegrating and summarizing information, the alerting needs to be done from the corresponding alerting tool.

Version 2.0 - to be released in time for christmas 2017.

For the 2.0 version we will only have the compliance feature on the agenda. We want to reserve development time for fine-graining the features that we added throughout the 1.7 and 1.8 release cycles.

Compliance

The underlaying architecture of the core application already tracks changes to the objects. How cool would it be, if we would extend that with WORM functionality, so that the history of an object in the IDB can not be tampered with. If a system represented a certain state at one moment, this should be visible in the IDB and it should not be possible to adjust the past to match expectations.

Roadmap for the adapters

This is a list of adapters we will focus on throughout 2017.

idbiaas

The idbiaas adapter crawls various Infrastructure-as-a-service providers. We've started with DigitalOcean as well as libvirt-based environments. The next ones we want to add:

  • OpenStack
  • Amazon AWS
  • CloudStack

Ansible adapter

Since Ansible became quite popular, and couple of our partners and customers showed interest in having support for Ansible, we will provide an ansible adapter. Part of this work will be to make sure the IDB can serve as an external node classifier / inventory provider for Ansible as well.

OPSI adapter

OPSI is a solution for client management and has (as a linux-server based solution) a strong focus on Windows desktops. This is something we do not cover very well at the moment. Our idbad adapter is an attempt to gather information in Windows-based environments. OPSI features a nice REST-API and not only holds information about the machines but since it is used to distribute software to the clients, we can gather all the infos on the rolled-out software from it as well.

PuppetDB adapter

We've originated with the IDB with a strong focus on Puppet as an information source. As such, the PuppetDB information retrieval is currently not handled via an adapter, but as an internal process within IDB-core. To assure that all data that enters the infrastructure database goes via the one central point, we're going to rework the PuppetDB connection to a proper adapter.

DE

Kopano - DeskApp als Standardmail-App einrichten

Posted by Ingo von Thielau on Tuesday, April 25, 2017

Kopano Webseite

Nicht gerade wenige Programme erlauben es, Dokumente direkt per E-Mail zu versenden. Sinnvoll ist das zum Beispiel, wenn man ein Dokument scannt. Das macht man ja nicht weil man es leid ist, aufs Papier zu starren. Eher will man es anderen zugänglich machen ;-).

Weitere Anwendungsszenarien:

  • Tabellenkalkulation: „Dokument per E-Mail senden“ öffnet direkt eine neue E-Mail mit der entsprechenden Tabelle als Attachment
  • Dateibrowser: Über das „Senden an“-Menü kann eine Datei direkt an eine E-Mail angehangen werden (… wenn man kein Drag&Drop nutzen möchte)

DeskApp als Standardmailclient unter Windows

In Windows gibt es die Funktion „Standardprogramme“. Diese erreicht man am einfachsten, indem man unter Start -> Ausführen oder in Windows 10 im Suchfeld neben dem Start-Button nach „Standard“ sucht (Bild 1). Windows 10 bittet dann um die Wahl der Standard-App für Kategorien. Die DeskApp wird dann als Standard-App für E-Mail gewählt (Bild 2).

Windows 7 hingegen listet alle Programme auf und lässt diese dann als Standard für alles was sie vorgeben zu können erheben. Ein Klick auf „Standards für dieses Programm auswählen“ listet dann alle möglichen Standards und bekannten Dateiendungen auf, die man manuell wählen kann. Das tut bei der DeskApp aber nicht Not – die wird einfach als Standard für alles was sie kann gewählt (Bild 3).

Click to enlarge Click to enlarge Click to enlarge

DeskApp als Standardmailclient unter macOS

Unter MacOS – das ist das OS, bei dem alles sehr intuitiv gehalten ist 😉 – ist alles anders. Hier muss die mitgelieferte Mail.app gestartet werden. Im Menüpunkt „Mail“ gibt es den Punkt „Preferences“, der den im Bild 4 zu sehenden Dialog öffnet. Dort findet sich das „Default email reader“-Dropdown, in welchem die Kopano DeskApp gewählt werden kann.

Click to enlarge

DeskApp als Standardmailclient unter Linux/Ubuntu

Ich nutze Ubuntu mit einer Gnome Shell. Hier findet sich die Einstellung der Standardclients als „Vorgabe-Anwendungen“, indem man nach „Einstellungen“ sucht und dort unter System -> Details wählt (Bild 5).

Click to enlarge

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle

EN

Kopano DeskApp autodiscovery

Posted by Felix Kronlage on Thursday, April 20, 2017

Kopano Webseite

There is a nice little feature in the Kopano DeskApp that makes you happy if you server an environment that holds a tad more than a dozen users and where you want to make it as easy as possible to login into the Kopano account for DeskApp users: autodiscovery of the servername.

Click to enlarge Click to enlarge

By adding a txt record to your DNS Zone, you can point the users based on their e-mail address to the correct WebApp address. Since the DeskApp connects to the configured WebApp host, this is where the setting comes from.

$ dig -t txt bytemine.net | grep webapp
bytemine.net.        170    IN    TXT    "kdiscover https://webapp.bytemine.net/"

Nice little settings helper!

EN

The felt dependency on Microsoft Outlook

Posted by Andreas Rösler on Monday, April 17, 2017

This is a guest post by my friend and colleague at the OSBA Andreas Rösler - one of the minds behind Kopano.

Andreas published on his blog a german post on "the felt dependency on Microsoft Outlook" that I really liked and wanted to have a english version of it available. Please enjoy reading!

felix kronlage

The felt dependency on Microsoft Outlook

On 10th April an international journalist team around Harald Schumann of the German tagesspiegel published the results of researches they did over several months about “Europe’s dire dependency on Microsoft“. The article mainly focuses on LibreOffice as an alternative to Microsoft Office. I can only underline all of the explanations, experiences and facts described in this article from my eleven years of experience in the OpenSource groupware scene.

This post is not supposed to be any form of Microsoft-bashing. It is not the one big company, but the relationship between the company and its customers from the public sector - the ratio can be equated well with a strong, but only felt dependency. Why a "strong, but only felt dependency"? Because it is not correct to accuse Microsoft alone for this dependency. The other side easily could break out. But it does not do it. Microsoft is also not the only group that behaves in this way. However, the number of those who do not work with its software on a daily basis is rather countless.

Our evolution with the market power

Us - this means my company, my colleagues and myself - have seen the market power of Microsoft on the clients-side already a long time ago. With Zarafa we have built an alternative solution. Our goal at that time was to offer a server for Microsoft Outlook, which does not have to come from Microsoft. This had initially technical advantages, then financial and ultimately the word "openness" played an increasingly important role. This openness meant Open Source, but also the interfaces to user management systems or other infrastructures. While Microsoft Exchange - to the present the Microsoft server component behind Outlook - necessarily requires a Microsoft ActiveDirectory, which requires a Microsoft Windows server and so on, we were almost open from the beginning for OpenLDAP, Novell eDirectory and all other user directories following the Open LDAPv3 standard.

The leading client for Zarafa was MS Outlook. Why? Convenience. There is hardly anyone in the corporate world who does not have it. In addition to MS Word and MS Excel, quoted in the named article, Outlook is not just another, but in my experience a much stronger lead into this dependency. With its office suite LibreOffice offers good alternatives to the two first mentioned solutions. Here, as a user, you may be bothered by the look and feel and the little things that you can solve with trainings, as described in the article. But which software is used as an user in order to efficiently manage his e-mails, appointments, tasks and contacts? Here the market is sown thinly.

When Outlook 2010 was released, we realized at Zarafa that things are going to change. Where previously fixed, standardized out of habits interfaces were, there were suddenly fixed dependencies to MS Exchange in elementary basic functions. Maybe you realized it: where the Outlook installation routine used to ask whether you have Exchange, Lotus Notes, Groupwise, POP3 / IMAP or another mail server, the program asks for Office365 or Exchange only these days - both are from Microsoft. Even their connection to Outlook was changed. Outlook can no longer be the leading client of a groupware that is not named Exchange or Office365. Last but not least, we created Kopano as a fork from Zarafa, which primarily connects its own clients - DeskApp and WebApp. In doing so, we address exactly the dilemma posed in the previous paragraph.

The addiction to Outlook

Regarding the daily workflow in offices without Microsoft Outlook, I would like to quote a department manager of one of our customers in the public sector. The task she gave me was so special in my memory:

"Please give us something - anything - so that those who can no longer work with Outlook do not feel like second-class people!"

No Outlook = second class people?!?

This quotation summarizes in all brevity and conciseness, why I wrote in the summary of a "strong, but only felt dependency". What has Outlook that other solutions - in this case our own - do not have? Already one and a half years ago I once listed ten thoughts to ask when it feels like being dependent on Outlook. And it clearly shows: One can replace Outlook. Today we are even a few steps further.

Alternatives

"What is there to counteract Outlook? It should only be the same as Outlook." - a requirement, which I have heard in the last ten years countless times. "What does Outlook do?", is my usual reaction to this. Very few things are listed which our DeskApp does not cover. Mostly one wants to edit e-mails, use shared calendars, send e-mails directly from his desktop. And the assistance of the management needs Outlook – A vicious circle: Why does the assistance need Outlook? Because she learned it. Tadaa This is precisely the "dependence on the one provider" which "slows down the technical progress in the public sector", as Dietmar Harhoff, Director of the Max Planck Institute for Innovation and Competition, was quoted in the article .

And there are, the alternatives. One of these is our Kopano DeskApp. This "non-Outlook" runs on Windows, on macOS and on Linux. It even looks a bit like Outlook. You can write emails, work together in calendars, delegate tasks - actually do all that Outlook can do. And if you want to send a document in Microsoft Word or LibreOffice Writer, the DeskApp jumps up and a new e-mail with the attached document is ready for dispatch.

New dependencies on the part of Microsoft have been installed slowly and steadily in the form of Sharepoint and Skype. The Kopano DeskApp supports a file integration to integrate any file storage one already has in use and web meetings to communicate quickly and directly with one another.

There is endless more. But the most important thing is: All this is open source. This is how we can earn money as an European company, which we have been demonstrating for years. And that is how we deliver confidence. Our source code can be checked. There are the experts - be it in the student community, at the Max Planck Institute, or in the company specialising in audits, which also do this occasionally. Vulnerabilities in terms of security or compatibility are thus sought and discovered by a swarm intelligence. This helps everyone and does not exclude others from using their knowledge and experience.

Last but not least, it is a basis for innovation. Our files integration was a community add-on of a student of the university of Graz. We liked it and have taken it into our product and significantly expanded it. The web meetings are based on spreed.me, which is published under the AGPL license as well. Partners integrate their solutions, such as e-mail archiving software and others. All this goes without complex contracts, manufacturer certifications and mutual license payments, which would have to be paid by the customer in the end. This is innovation made by Open Source!

Summary

I could still write endlessly on this subject. With our customers and those who want to become one, and also in the OSB Alliance, I am almost always talking about these issues. But the main message of this blog post is: There is a dependency on Microsoft. This is, first and foremost, in the minds and is technically predominantly only a felt dependency. Courage is the only thing needed by the single authority to go the step away from Microsoft. Some already did it. We and many others in our ecosystem do everything to enable more of them!

Thanks to the journalist team for this work! The article describes everything I have experienced again and again for more than ten years.

Older posts: 1 2 ... 22