BM 4.0 beta + Outlook: step by step

BlueMind v4.0 beta is finally out ! Time to test and learn. Don’t hesitate to request a trial subscription to make the best out of the new version.

Making a big announcement is great, but showing software that actually works is better. We’re still putting the final touches to BlueMind 4.0, in the meantime we’re releasing a beta version so you can test, use and abuse its native Outlook support. It’s all yours!

But first, a few caveats. BlueMind 4.0-beta:

  • Is available for new installs only
  • Must not be used in production: updates will not be available
  • Requires a trial subscription for Outlook support

About this last point: BlueMind’s most significant new feature – native Outlook support, which this article is about – is included in the subscription. If you don’t need Outlook support, you can try BlueMind 4.0-beta without a subscription – in which case you don’t need this article either 😉.


We make every effort to make BlueMind administration tasks easier. However, some of the operations described in this article require a minimum amount of technical knowledge: specifically, about certificates and network configuration. 

We also recommend that you work on virtual machines and use snapshots so that you can go back if you encounter an error.


You can find our installers at BlueMind Download. Make sure you select the latest version 4.0. Installation instructions are the same as for previous releases.

The only extra pre-requisite is a second computer running the latest version of Windows 10 and Outlook. Important: Outlook must be 2013 or above. You need to have admin rights on the system, and all systems (BlueMind, Windows/Outlook) must belong to the same local network (e.g. two virtual machines from the same provider).

Make sure you keep note of the external url you are using during installation: you will need it to setup Windows access. In this step-by-step I am using bluevm.test.loc. Also keep note of the server’s IP address, in my case

The bm-mapi packages

You must install the bm-mapi package before you create Outlook users. The optional bm-plugin-core-mapi-support enables push notifications from bm-core, you should install it too.

Contact us to get a trial subscription, which will give you access to BlueMind’s fee-based ressources, including this package.

Deploy your subscription on the server, then install the bm-mapi package using aptitude or yum depending on your distribution. This package adds native Outlook support to BlueMind.

Trial users

You can now log in as administrator to create your first user. Be sure to set up an email account for them!

Setting up Windows


If you’ve set up an authentic certificate (e.g. LetsEncrypt) you can skip this step.  

BlueMind uses HTTPS, and self-signed certificates are generated upon installation (these are obviously replaced in production by certificates issued by a certification authority, but it isn’t the case in this instance).

The root certificate is available on the server:

  1. /var/lib/bm-ca/cacert.pem

You can copy this file on the Windows computer and import it into the “Trusted root certificate authorities” store. To do this:

  • Rename it in cacert.cer (Windows 10 does not recognise the pem extension by default)
  • double-click the file, “Install Certificate”, “Local Computer”, “Place all certificates in the following store”, select “Trusted Root Certification Authorities” and confirm.

HOST files

If the Windows system has direct access to the external url you have used to configured BlueMind, you can skip this step.

You now need to edit the file C:\Windows\System32\drivers\etc\hosts to add entry points and save you having to set up a DNS.

You need to add the following code line:

  1. bluevm.test.loc autodiscover.test.loc

Make sure you change the IP address, the external url and the auto-discover url! To get your autodiscover url, replace the first member of your external url with autodiscover.

The moment of truth

If everything has gone smoothly until now, you can start Outlook:

  • Create a new Outlook profile for the trial
  • Enter the email address of the user you’ve created earlier.
  • Select “Exchange” as account type
  • Enter the user’s password by checking “Remember my login credentials”

After a little while, Outlook will inform you that the account has been created. Click “Finish”.

You’re good to go! Outlook now communicates natively with BlueMind! Enjoy your testing!

Final tweak (for perfectionists)

To be perfectly honest, there’s one more setting you can specify for Outlook to work better in the long term (although your trial installation isn’t designed to): in your Outlook account settings, “keep mail offline”[must be set to “All” (maximum time).

Suivez nous :

Free softwares and free beers, legends and myths

When we talk about software, the word free can be taken to mean different things. As Richard Stallman famously said: “This is a matter of freedom, not price, so think of ‘free speech’, not ‘free beer’.” However, free in the sense of free of charge is always lurking in the background. In the collective imaginary, free software is software you’re not paying for. True or False?

(and reality)

Once upon a time…

Free or open source… both refer to software whose code has been made public and is freely available. There are varying views, however, as to what the use of this software implies.

Obviously, there are licencesover one hundred altogether — which rule what you can or cannot do with an open source code. But beyond these rules, there are opposing philosophies.

Let’s begin with a little lexical background.

The term “Free Software” is the oldest. It is included in the name of the Free Software Foundation (FSF), an organisation founded in 1985 by Richard Stallman to protect and promote free software. The term “open source”, on the other hand, was coined by Christine Peterson and adopted in 1998 by the founders of the Open Source Initiative.

In the 1990s, the term “open”, when referring to software code was sometimes used to mean that the code was inspectable, visible and available for access.

The term “open source”, as defined by the OSI, clearly indicates that open source doesn’t just mean that the code is available for access but also that it can be forked and used free of charge indefinitely.

To the FSF, users of free software are free to run, copy, distribute, study, modify and improve it. “Free software” is about freedom, not price.  

While the FSF and the OSI use different definitions, in practice they refer to the same thing. The FSF, however, is a lot more dogmatically and politically-oriented than the OSI and actively campaigns through its figurehead, Richard Stallman.

The terms “open source” and “free software” can therefore be used interchangeably, unless when discussing history or terminology itself.  

Grandmother’s lasagna

This being said, one question remains: is free software free of charge? As Richard Stallman famously said: “This is a matter of freedom, not price, so think of ‘free speech’, not ‘free beer’.”

Software developers are like you and me. Even with the best of intentions, they need to make a living, and voluntary work doesn’t put food on the table. Open source or free software – as you might like to call it – isn’t profitable. And if you’re not selling a product, you must sell a service.

Take lasagna. The recipe has been available to all for years. Anyone can make lasagna. The recipe has even been forked into new versions: vegetarian, vegan, fish-based… And yet, when you go to your local Italian restaurant, you’re still willing to pay to eat it. 

It’s the same with open-source solutions. The code – the recipe – is openly available, but the service, the support, updates, technical skill – the dining room, the service, the washing-up and the cook – must be payed for. Open-source software publishers therefore have a key role to play in its appropriation. “Clients are looking for a solution to their problem, not for a source code” said Pierre Baudracco at the Paris Open Source Summit 2018. “Take theBlueMind code, it’s openly available. But when it comes to the technical expertise required to deploy, maintain, and update it and the ecosystem built around it, the network of certified partners to implement it, etc., only we are able to provide this.”

Magic formulas

Open code therefore doesn’t mean free of charge. It does, however, mean “auditable”, i.e. anyone can look into it. Just like you can read the recipe and the list of ingredients for lasagna. This is extremely important, crucial even, in a world where any personal data is a potential source of revenue.  

It has been recently reported that Facebook had allowed Netflix and Spotify to access its users’ private messages, in the wake of manyother scandals in connection with inappropriate app behaviour.

Proprietary software has other flaws, beginning with being owned by major international players, mostly American ones (typically identified with GAFAMs). They lock businesses in by making them dependent on increasingly more expensive software and services and non-negotiable terms. And remember, although nothing can be said to be certain except death and taxessoftware giants are known not to pay the said taxes.

In a December 2018 report on Open-source or free software as an alternative to major suppliers, French CIOs took a strong stand against this domination, threatening to turn to free software.

But why didn’t they do it sooner?

Of wizzards and men

Free software is already everywhere… in infrastructure layers, where end users never see it: network and security layers, application servers, web servers, virtualisation, etc. 

So, why is open source still the underdog with the general public? There are two key reasons:

  1. Because open source is first and foremost designed by technicians for technicians. 
  2. Because the front-end market was dominatedvery early on by major software publishers through lock-in practices.

The first point makes simple sense: not everyone is able to understand or use source code. A company will never tell an employee, “here’s your computer, it runs on Linux, go ahead and set up your email and all your applications yourself”.

The second point, however, highlights the real issue: entire armies of software giants’ UX designers have shaped user experience to the point of locking them in completely. In other words, they have made us develop habits that are so deeply ingrained today that we’ve become reluctant to any change. Think about how difficult it is to switch from Windows to Mac and vice versa, or from iOS to Android. Now imagine giving up Microsoft Office in favour of Open Office. The buttons aren’t even in the same place: “how do I sort this bleeping column?!?” (true story).

And yet… Thanks to the open-source software publishers we talked about earlier who have understood that clients expect a solution rather than a construction kit, open-source solutions are slowly but surely creeping up from lower layers to end users.

“This is precisely the issue we’ve tackled with BlueMind v.4.0” explains Pierre Baudracco, CEO of BlueMind and president of the Paris Open Source Summit 2018 Programme Committee. “Email is not only the most widely used tool in businesses but also undoubtedly the most critical. Any breakdown can lead to pandemonium. Most users have been fed Outlook, Microsoft’s mail solution. CIOs want to avoid a meltdown and they’d rather play it safe by safeguarding user habits. Until now, open source merely offered an additional, more or less compatible solution. We’ve decided to address the issue the other way round by focusing on user needs. They want Outlook? Fine, we won’t touch it. However, we can change everything behind it.”

They lived happily ever after

If you’ve made it to this section, you now know that free software doesn’t necessarily mean free of charge, and that you are probably already using some without knowing it.

What you need to remember is that today, there are many trustworthy and proven alternatives on the open-source market that can allow you to set yourself free from major US publishers. This is not about dogmatic or philosophic resistance but a truly societal choice. Choosing a European open-source solution is about promoting innovation and jobs, preserving your independence and contributing to our states’ digital sovereignty

This article, like all our other blog articles, is open to discussion. Feel free to tell us what you think on LinkedInTwitterFacebook or our website.

Suivez nous :

The Blue Orange Mystery

The latest version of BlueMind’s mail solution was announced at the Paris Open Source Summit 2018, as we pressed oranges on our exhibition stand. The whole campaign was built around a blue orange, but… why? To understand the rationale behind the Blue Orange, you must understand BlueMind’s v.4.0’s mission and why it has taken so long – 5 years — to come out.

Continue reading “The Blue Orange Mystery”
Suivez nous :

DevOps and Continuous Integration: a look at BlueMind’s quality approach

The term DevOps is rather recent on the global IT landscape, but it’s already risen to the top among the most effective industry practices. According to the Gartner IT consultancy, in 2015, 25% of 2,000 biggest world corporations were moving towards a DevOps approach. More than a working method, it is above all a cultural change that aims, as its name suggests, to bring development and operations closer together. DevOps has a twofold objective: to speed up update deployment and ensure high quality levels.

Its secret lies in cooperation and sharing: developers and system operations managers work together to provide continuous software delivery. Development cycles are shorter, quality assessed throughout the project and deployments more frequent.
“DevOps is an understood set of practices and cultural values that has been proven to help organizations of all sizes improve their software release cycles, software quality, security, and ability to get rapid feedback on product development.”Puppet Labs, “2017 State of DevOps” report.

BlueMind has chosen to implement a DevOps approach through a process of continuous integration. Let’s have a look at what this entails.

A new paradigm

Traditionally, developers didn’t share their work with the rest of the team and would go off on their own for long periods of time. They’d only integrate code modifications when their work was done. Developers didn’t actually know what the true impact of an update had over the whole application. As a result, issues were only identified down the line and they were difficult to pinpoint, thereby delaying delivery.
As for operations departments, they sometimes had to wait several months for testing and deployment to satisfactorily respond to user needs, which by then had probably changed. Both teams – development and operations — didn’t have the same objectives and therefore didn’t have the same priorities.

On paper, software requirements are clear, set in advance and static. Developers work on the code, and operations teams work on implementing it on the company’s systems. On paper, that is.
In the real world, IT evolves so quickly that it is impossible for project specifications to stay the same throughout. For software publishers, the “project” never ends! Software must be released as quickly as possible, but it must also evolve constantly. Adding new functionalities must as easy as possible and bugs must be identified so that they can be fixed. New features must not disrupt what already exists and take into account all possible configurations and situations. There’s no D-day for product deliveries like in the past.

DevOps practices – including continuous innovation – aim to put an end to the conflict between Dev and Ops – and find a balance between innovation and stability.

DevOps: improved dialogue between teams

The DevOps approach is about setting up an overarching process involving everyone concerned, whatever their initial role. No more isolated and hyper-specialised individuals, development and operations teams work together throughout the entire life cycle of an application, from design and testing to deployment and operation.

Teams share many responsibilities and combine workflows. This limits efficiency losses and saves time.

“At BlueMind, no one is moving forward by themselves. We encourage collaboration and sharing to promote operational efficiency. We have a common objective and a plan – defended by the product or feature owner – we work towards together. The whole team can keep up with projects, ideas and everyone’s stumbling blocks”.

Dominique Eav – Quality Bandmaster at BlueMind

The time spent sharing know-how, ideas and knowledge should largely be made profitable by the efficiency gained in delivery quality, anticipated issues/errors and faster troubleshooting.

Continuous integration

Put simply, integration consists in putting together pieces of code and getting them to work together. This often takes great dedication! Integration often involves multiple projects and environments, each environment involving organising the module concerned differently as well as construction, testing, validation and deployment phases. Continuous integration solves these problems by involving all stakeholders in a project from development to operation.

Continuous integration is the set of practices that allow developers to integrate code changes into a centralised repository regularly, automatically create and run testing sessions, and then deploy build results if all lights are green. This process makes it quicker to detect and fix bugs, helps improve quality and reduce update validation and release time.

Test results history.
For any given test, you can see what’s happening now and in the past. A “failed” on a test that passed before points to a regression

Every time the source code is modified, the result is checked for regressions or defects in the untouched parts of the application. Bugs are identified more quickly and therefore fixed more quickly. Validation and release time are reduced and, obviously, final quality is improved.

“We largely use the principle of pull requests. This mechanism allows developers to share and validate their work whether it’s finished or not. The developer may submit a pull request at any time for review by the people involved. It’s a lot more than mere validation – it’s a genuine discussion about the technical choices for the functionality under review. That way, we make sure that the whole team stays up to date with technical evolutions and choice integrity”

— Dominique Eav Quality Manager at BlueMind.

Dashboard on the build of a (master) branch
This diagram shows the test results for the different build stages and earlier builds

Automation: the cornerstone of continuous integration

Compilation, one-off and operational tests, product validation, performance tests… all are key but time-consuming activities, not to mention susceptible to human error, which is always a possibility. The principle of continuous integration relies on test automation to save time and ensure maximum quality levels.

When a developer writes code, the tool automatically checks that it complies with common rules set for the whole team. This procedure ensures the quality of the newly-written code and its stability over time as it complies with development best practices.

This code analysis tool shows the test coverage on the code. You must seek the highest coverage possible.

BlueMind uses Jenkins to drive its continuous integration chain. This software tests and reports changes made to a large base of code in real time to detect problems quickly.
We use Jenkins to build and test our development branches (features or corrections) whose changes continuously integrate our release branches (3.0, 3.5, 4.0), on all supported Linux distributions (8 for BlueMind 3.5.9). The BlueMind core comprises more than 500 modules and interacts with many AddOns you can find at the Marketplace. These have also been built, tested and deployed through our continuous integration chain and are subject to the same compatibility and quality constraints. More than 3,000 tests are carried out on every build. Such a degree of complexity would be impossible to manage manually! What’s so clever about continuous integration is that tasks automatically run one after the other as we aim for process industrialisation.

“Our approach is consensual and pragmatic. We implement and improve our processes to make our team members’ lives easier, as opposed to complying with an imposed set of project specifications. The resulting automation allows us to be fast and helps potential problems to surface as early as possible. Each brick in our continuous integration chain is a safety belt.”
— Dominique Eav Quality Manager at BlueMind.

This static code analysis tool assesses classes: it measures technical debt, i.e. the time required to fix problems found in some part of the code.

In addition to eliminating tedious tasks, automation makes the deployment process more reliable while increasing delivery frequency. Teams can then concentrate on improving existing features or quality control rather than performing tests manually.

Specific benefits

With continuous integration, development teams save a huge amount of time as each software modification is immediately tested. By compiling code regularly, software modifications that cause trouble are quickly identified. Developers have a quick overview of the regression they’ve caused. Conflicts between the software and the ecosystem it will be operating in are detected early on.
Throughout the development and deployment process, the entire team works very closely towards a common goal: the success of the project as a whole, not just their own part.

When the whole project team is agile, a new functionality or a bug correction can be released quickly – or cancelled as the case may be. A working version of the software is always available and there’s no need to wait for the software to be released to find out whether it works. With BlueMind, we first release new features or software patches internally. This process is called “eating your own dog food“, which means that we are the first ones to use our solution.

On the client side, continuous integration makes deliveries faster with more frequent updates while ensuring the best quality levels possible.

In conclusion

Installing a scheduler like Jenkins isn’t enough to implement continuous integration. One of the Manifesto for Agile Software Development’s statements is that individuals and interactions are valued over processes and tools. A DevOps approach is about involving everyone’s responsibility. The DevOps culture implies adopting a transparent approach based on communication and collaboration between IT/Operations and development teams. It is a great approach for constantly-innovating businesses!

BlueMind was built on these principles from the start to ensure the best quality levels in a complex environment. The agility this gives us enables us to deliver first-class, stable products by industrialising processes between operations and development.

Suivez nous :

Suggestion Box – a new approach to deal with new features

Our job as a software publisher is to listen to our users’ expectations and enhance our product to meet them.

Being open source is what makes BlueMind unique. Yet openness can sometimes be detrimental to its development.

As a result of our product’s success, we’ve had enormous amounts technical and functional feedback and we’ve had to organise ourselves in order to process it.

Business model

Before moving on to the thick of things, we should explain what our job as a software publisher means, our business model and its impact on our organisation.

As software publishers, we focus on software development, product enhancement and technological partnerships. Our target market isn’t country or business-specific. Today, everyone needs email, and BlueMind responds to this need whether you are an SME or a multinational corporation.

To achieve global coverage, we work with a distribution network made up of partners who implement the projects for our clients and/or set up SAAS platforms.

Our network of partners enables us reach a must greater number of potential clients.

This has two consequences:

  • most clients come through our partners, which means we don’t know all of them
  • our number of clients is going to keep growing

As a result, we must set up a series of tools and methods to collect our clients’ feedback and requests in order to process them as best we can.

Organising Development

In the DevOps sense, as shown in this chart by our Normation colleagues, in the process from application development to production implementation, two parts are involved: BUILD and RUN.

The job of a software publisher is to BUILD, i.e. to take business requirements to create “application binaries”. In the Agile sense, business requirements can take different forms (stories, epics, etc.)

BlueMind’s R&D team has been using agile methods since the product’s early days. This has allowed us to develop features quickly, within a specific context. A whole series of automations and tests allow us to deliver new versions with new features quickly.

This article looks at the issue of handling large amounts of business requirements: how can we process them and incorporate them into our R&D appropriately?

Managing business requirements

Why manage them? People ask for things and we do them!

If only things were that simple. We’d need endless resources and all requests would have to be consistent, among themselves and with our vision. In the meantime, we have had to sort through requests and select them to feed a roadmap with a set of features that go into a Backlog.

The backlog contains a number of features which have to be sorted through and validated by a Product Owner. The features at the top of the backlog are processed by our R&D team first.

A simple qualification process

We had set up the following simple and comprehensive feature qualification process (as the young Padawans we were!).

  1. Understand the request
  2. Validate or reject the request
  3. Search for duplicates (who knows whether other users may have made the exact – or not so exact – same request!)
  4. Create a story for the backlog
  5. Place it in the backlog according to its priority status set by the Product Owner
  6. Link it to an Epic, if the story is too big

In theory, this process had 6 steps “only”.

This seems straightforward enough, but it becomes infinitely more complicated when you’re dealing with a large inflow of requests (entered by people who must be clients, but whom you don’t know, much less do you know their vocabulary and their expectations which tend to be too vague). As a result, your backlog becomes, well, backlogged. Looking for duplicates can be time consuming when you’re dealing with a hundred features or so.

In our case, requests come from various sources:

  • end clients
  • our partners
  • internally (developers, sales people, pre-sales people, etc.)
  • the software user community

This adds up to huge amounts of people potentially sending feedback and requests.


Most people believe that their requirements are generic, but in most cases they aren’t. Requests aren’t always expressed in the most straightforward manner and everyone thinks their feature is indispensable to their everyday software uses!

Our backlog: on hold

As at January 2015, this was our backlog’s status:

  • 140 features not sorted
  • 470 stories in the backlog

Among these stories:

  • some were important (implementation of a major, structuring feature)
  • others were less important (e.g. evolution of an existing feature)
  • others were small but legitimate (being able to sort by column: feasible, interesting, but high-priority?)
  • others were irrelevant, and possibly clutter (with all due respect to our users “the button would be better in yellow”)

The main issue isn’t so much the flow of feature requests but rather the way they were created and we processed them.

As for all IT projects, we’d set up a bug tracker. In most bug trackers — if not all, as far as we know –, bugs and features are essentially processed in the same way (by default). Typically, the request form is almost identical and a drop-down menu allows users to set the request as “issue”, “bug” or “new feature”.


This is where the trouble is: a bug isn’t a feature! They are two distinct processes with different objectives!

Unfortunately, in bug trackers, the difference between a bug and a feature isn’t clear enough.

A feature ends up having the same level of time constraint — and possibly requirement — as a bug, which shouldn’t be the case.

A bug:

  • must have a resolution time-frame and depending on the type of service offered, must follow an SLA
  • must be corrected. It is a fault that must be entered into a correction cycle.
  • a specific workflow must follow its progress (open, pending feedback, corrected, deployed, “won’t fix”, etc.)
  • is critical
  • significantly impacts users, who must be informed of its progress.

A feature:

  • is a request for an enhancement
  • does not have a deadline (contractually)
  • is not critical (contractually)
  • does not require feedback to users
  • can be considered and accepted…  or not

This means that by nature, bugs and features are processed in a dramatically different way.

The Suggestion Boxlogo-sb

This is why we’ve decided to work differently, to reconsider how we handle features completely. First, we won’t call them “new features” or functionalities, from now on we’ll call them suggestions.

As a result of our analysis, we’ve concluded that to optimise how “suggestion requests” are processed, it is important for the requirement to be described as well as possible by the submitters themselves.

This isn’t a technical issue! But how can we get submitters to be more proactive? The vocabulary we use is important, and it is a first step in conditioning users:

  • users will “suggest” rather than “request”!
  • “I want” becomes “I suggest that”, “at some point, I’d like”

This is how the Suggestion Box was created. This dedicated UI is principally designed to browse through existing suggestions.

Credit and discipline

The Suggestion Box must encourage users to ask themselves several questions before they submit their suggestion:

Functional questions:

  • What is the use of my proposed feature and what will it do?
  • What will be its impacts on the BlueMind software as a whole?

Planning questions:

  • Has another user already made this suggestion?
  • Is there a similar existing suggestion?

If a suggestion can be created immediately, it doesn’t encourage users to think about their expectations. Therefore, each requirement turns into a request, with no prior analysis. And it will have to be analysed before the feature is turned into a story (how it is broken down).

This is exactly what used to happen when we allowed the creation of a “new feature” in our bug tracker: “all I have to do is select from a drop-down list and fill in a title”…

We must therefore guide our users through the process, via a suggestion self-service: the Suggestion Box!


The Suggestion Box was created with the following specifications which are deliberately basic in order to keep the procedure simple:


  • Search

The search is important as the UI’s purpose is to go through existing suggestions. We therefore need a powerful search tool.

  • Suggestion not created if no prior search

To encourage users to search for a similar request, suggestions cannot be created from the home page. A suggestion can be added only if a search doesn’t produce any relevant results.

  • Category

Still in an attempt to get as much information as possible, suggestions must be categorised to help group requests logically and facilitate searches.

  • Votes

Votes are designed to help rank requests. They will help identify the most popular requests.

  • Comments

If a request is similar to an existing suggestion, comments allow users to give another view on the suggestion and provide new arguments rather than create a new one. Adding to existing demands rather than creating a new one is more useful and it allows a suggestion to collect more votes.

  • No status

The point is to allow suggestions to evolve with the community of users and let them become more specific, better-defined and respond to the expectations of as many people as possible. Anyone can add a comment and enhance their vision at any time. BlueMind takes it over at the appropriate time and sets it as “accepted” to draw up the final specifications and carry out the suggestion.

How does BlueMind use the Suggestion Box?

Designing a software RoadMap is a publisher’s job. The Suggestion Box is a component that contributes to the RoadMap among many others. The Suggestion Box is not the absolute basis for the RoadMap, but it will serve to complement the feedback and planned internal projects.

The number of votes for a suggestion tells us how popular a request is. However, BlueMind may decide not to give priority to a suggestion with a large number of votes and prefer a less popular suggestion.

This is because for technical, planning, consistency or strategic reasons, the Product Owner is the one who makes the final decision on a sprint R&D.

Moreover, “internal” tasks, not requested by users (change in API, development library, etc.) may be given priority in order to plan for the possible development of an advanced feature at a later time.

When we decide to upgrade a component (calendar, administration, contacts, etc.), the Suggestion Box is used to find out our users’ expectations and what improvements can be made given a variety of constraints.

Categorising the Suggestion Box allows us to restrict the analysis of suggestions to the module we have chosen to upgrade.

Bottom line

Two years after the Suggestion Box was launched, feedback is extremely positive.

Today our backlog includes 78 stories broken down into 22 EPIC while previously, we were struggling with 470 stories in backlog and another 170 non-analysed features.

The Suggestion Box includes 224 suggestions, 662 votes have been made  on 134 suggestions. 50 suggestions have been carried out, some with many votes (up to 46), some with fewer votes but that were considered high-priority.

Additional Information

You can find BlueMind’s Suggestion Box at

Our development is OpenSource and you can find everything you need to know about this project at

The Suggestion Box is the result of a lot of in-house discussion and reflection, in particular with Dominique Eav, our quality manager and developer of the Suggestion Box.

And, as we keep updating the Suggestion Box, you’re welcome to create a suggestion for the Suggestion Box!



Suivez nous :

Tutorial: writing a BlueMind add-on

So here you are with your shiny BlueMind setup. You’ve heard about our grand architecture plans, extension points, p2 platform, REST API, but you find it hard to get started. Rejoice! This article has been written just for you.

You need to know some java, and be more or less familiar with maven.

Your goal: a dummy scheduled job

Let’s say your BlueMind add-on will be a scheduled job. You can view the BlueMind scheduler as an internal CRON that will execute jobs when planned, which is pretty handy to assist you in administrating your server.

This scheduled job will log some dummy stats – basically what we’ll do is just a placeholder to demonstrate how to glue the REST API bricks together. Doing something more meaningful will be left as an exercise to the reader 🙂

Your scheduled job will list all mobile devices for all users for all domains of your BlueMind server. Just because you can. We’ll call it MobileDevicesListingJob.

A word of caution

Don’t forget that when you’re using the REST API with a BlueMind server, you’re dealing with real users data and it’s pretty easy to make mistakes, since everything you can do in BlueMind can be done using the REST API. There won’t be a confirmation screen like we do in the Administration Console: when in doubt, just don’t. Or better: do your API tests on a sandbox server. We won’t be modifying data in this tutorial, so you should be safe, but you’ve been warned.

Bootstrapping a maven project

If you take a peep into BlueMind internals, it’s OSGi bundles all over the place. Since we want to build a BlueMind add-on, we depend on BlueMind target platform.

This target platform is published as a p2 repository, and you can find it at

As the URL implies, this is the latest and greatest BlueMind target platform. It will get updated every time we publish a new BlueMind release – and hopefully upgrading won’t break your work.

We’ll be using Tycho, which makes it easy to build your bundles with maven. Here is the simplest project_structure. Download it and extract it somewhere.

This project is restricted to the bare minimum. I won’t delve into the details of the configuration files since they are not BlueMind specific, but I want to emphasize two points:

  • pom.xml declares where to find the BlueMind target platform
  • plugin.xml declares what extension point we’ll be using, namely scheduledjob_provider, along with the name of our soon-to-be-written java class: org.example.mobiledeviceslistingjob.MobileDevicesListingJob

The rest is just boilerplate configuration.

Alternatively, you could also use our maven archetype to bootstrap your project. Or clone bluemind-samples to find an existing add-on to adapt. There are more than one way to skin a cat. Or a duck. Well…

In the project directory, you can run:

mvn install

Et voilà! You’ve built your project, but it won’t work yet: there’s no code.

Eclipse to the rescue

You may just go ahead and write the java code using your favorite editor, but here is how you’ll do with Eclipse:

  1. Import your maven project into your workspace
  2. Tell eclipse about the BlueMind target platform: go to Preferences, search for “Target Platform”, and add a new target platform definition. You need to start with an empty target definition, pick up some name (for instance “BM target platform”), then add the URL above as a new Software Site location:


Select all (the “Uncategorized” checkbox in the previous screenshot), click on Finish and you’re done. Careful, you need to select the target platform we’ve just defined before you close the Preferences window.

Setting up the dependencies

We need to declare what parts of the BlueMind target platform we’ll actually use in the MANIFEST.MF. Our REST API online documentation for will help you to cherry-pick the parts you’ll need. If you’ve installed the optional bm-docs package and given the Api docs permission to your user, this documentation should be available right in the BlueMind UI:


Icing on the cake: this inline documentation is interactive, so you can execute calls using the javascript client. Beware, the previous caution notes also apply! (the harm you’ll be able to do depends on your logged-in user’s rights)

The BlueMind source code is also be a good place to find inspiration.

Here are the dependencies we’ll need, just add these lines at the end of the MANIFEST.MF:

Require-Bundle: net.bluemind.domain.api,
  • net.bluemind.*.api : the REST apis we’ll need to explore domains, users and mobile devices
  • net.bluemind.scheduledjob.scheduler: to make use of the extension point
  • to setup authentication to the REST API
  • net.bluemind.slf4j: logging classes – since we won’t do much more than log some information at the end of the day

Have fun with the REST API

So go ahead and create the class we’ve declared in plugin.xml: org.example.mobiledeviceslistingjob.MobileDevicesListingJob. It has to implement IScheduledJob for scheduledjob_provider to be able to plug it in. Here is the complete code. I will only include here the actual business logic:

// logger will write in bm core logs (/var/log/bm/core.log)"Executing MobileDevicesListingJob");
// sched will write in the execution report, that you can send by mail in the Job setup UI, "en", "Collecting mobile devices data for all users...\n");
// write header row for the data to come, "en", "device; isWipe; lastSync; user; domain");
// initialize client for domain service
IDomains domainService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
// loop on all domains
domainService.all().stream().forEach(domain -> {
  // initialize client for user service
  IUser userService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
      .instance(IUser.class, domain.uid);
  // loop on all users
  userService.allUids().stream().forEach(userUID -> {
    // grab full details for user
    ItemValue<User> user = userService.getComplete(userUID);				
    // initialize device service for each user
    try {
      IDevice deviceService = ServerSideServiceProvider.getProvider(SecurityContext.SYSTEM)
          .instance(IDevice.class, userUID);
      // loop on all devices
      deviceService.list() -> {
        // collect info for this device
        List<String> deviceInfo = new ArrayList<>();
        // write a line in the report				, "en", String.join("; ", deviceInfo));
    } catch (ServerFault exception){
      // Skipping this user since she doesn't have a "device" container


Deploy to your BlueMind server

You can compile this code with

mvn clean install

Then drop the resulting jar (target/org.example.mobiledeviceslistingjob-1.0.0-SNAPSHOT.jar) in the folder /usr/share/bm-core/extensions of your BlueMind server. Then you can restart bm-core

/etc/init.d/bm-core restart

And your job should appear among the Scheduled Jobs in the Administration console. You can then execute it, schedule it, send the report to your best friend, it’s all yours.

Caveat: if you need to recompile/redeploy your extension, you may need to delete bm-core’s cache to be sure the fresh jar is picked up:

rm -Rf /var/lib/bm-core

Talking REST from the outside world

You’ve noticed we’ve used a ServerSideServiceProvider to initialize the REST API services, but you can of course talk REST from the outside world, for instance by using our python client. You need a BlueMind API key to do so.

Share your work!

Don’t bother sharing your MobileDevicesListingJob, but once you’ve done something useful you may want to share it on BlueMind Marketplace. We’ll be looking forward to your contributions!

Suivez nous :

BlueMind turns Thunderbird into a true collaborative client!

bluemind-thunderbirdA frequent obstacle to the adoption of an Open Source mail server is the predominance of Outlook as a thick client because Outlook always works differently – and therefore more or less smoothly – with severs other than Exchange… until BlueMind’s soon-to-come innovation which will bring native Outlook support!
This is a matter of user habit, but this is also due to a virtually inexistent offering of good open source, multi-platform email clients (for email and collaboration).

The most popular open source email client is Mozilla’s Thunderbird which runs on Windows, Mac, Linux and others.

But although Thunderbird is a good email client, it is a poor collaborative client. Its calendar feature is provided by an extension – Lightning – which has never been entirely satisfactory for enterprise use (in terms of ergonomics, performance, etc.): users fail to understand having to use two different interfaces with different ergonomics and features depending on how they access it (web or thick client).

BlueMind offers comprehensive, user-driven Thunderbird management, which precisely addresses these issues.

Discover Thunderbird as BlueMind’s natural thick client!

Continue reading “BlueMind turns Thunderbird into a true collaborative client!”

Suivez nous :