Open source is still viewed as a way to save money while breaking free from proprietary vendors and lock-in practices. As a result, some companies and public organisations have undertaken to try and redevelop existing open-source solutions in-house, without resorting to their publishers, in an attempt to gain more control and self-sufficiency. You won’t be surprised to hear that this doesn’t work. This only leads to failure and unkept promises.
Why is that? Because what software publisher do, including in open source, isn’t something you improvise, and these organisations wholly underestimate what it involves. Let us tell you about this still little known and unsung line of business that, in fact, produces 90% of open-source software.
Key premises
For the purposes of this article, and to understand open source in general, it is important to make the distinction between:
- Technical components, whichareoften managed by a community, and are not made for end users but for engineers or developers to build solutions. This includes database middleware and infrastructure components such as Nginx or Cyrus, whose contributors are, typically, software publishers!
- Solutions designed for end users, such as office suites with management or email applications for example, for which user acceptability, ecosystem and overall environment are just as important as performance.
This article discusses the latter category.
The wariness Tech Giants leave in their wake
Bounty hunter-like behaviour, “sell more” rather than “sell better”, unbalanced commercial relations, technological and contractual lock-in practices, failure to comply with GDRP, extraterritorial rights… the list of reasons why public and private organisations are seeking alternatives to monopolistic software solutions, in particular American ones, is endless.
But some IT departments that resort to open source tend to turn what may be legitimate wariness towards a few major vendors and their outrageous behaviour into a wariness towards software publishers at large, who they view as parasites.
We also find this wariness – although increasingly less so as open-source software matures – in people who simply can’t comprehend that you’d have to pay for open-source software and translate this as “open-source software must be restricted to providing a service” or “end users must decide what they should pay”!
So, you’re saying that my project is… a product!?
These organisations choose to “build” their solutions in-house and commission open-source service providers for development or support activities. This is appropriate when no off-the-shelf solution is available to address their particular issue or meet their specific business requirement. But this makes no sense and it is unfailingly counterproductive when a standard, industrialised solution meeting this need already exists. You can’t develop a standard solution through services or support.
Carrying out a project isn’t writing software! The cost and actual tasks involved in developing and maintaining standard software bear no comparison with what is required to carry out a project. As time goes by and the software evolves and the number of versions increases, the difference is greater still. To maintain existing software, continuous and growing effort has to be put into testing and quality assurance. Technological baseware evolutions and technical debt quickly become the most time (and money) consuming tasks.
The above chart illustrates the costs distribution in software development – Chart source
Some client want to buy software by only paying for services
At the other end of the spectrum, the vision of what a client is prepared to buy as a service (new feature development and support) bears no comparison with all the work needed for a publisher to provide a high-quality, lasting solution.
When you develop your first software commissioned by your first client, things are straightforward. You have just one task to perform: developing features. But this only works for your first version and your first client – the first one!
The machine that builds the machine!
Typically, the starting point for a project involves developing a program or putting together a few components to resolve a particular task for an end user. Unsurprisingly, they are happy. They are given a solution to their specific request.
The developer or provider then thinks: “Hey, this is something others might find useful, and I have ideas for features I could add. I’m going to turn this into a product! I’m going to get a few colleagues together to pool our resources and help finance this.”
That’s a huge mistake. The gap between a given project and software is usually a hundred times bigger than expected. Moving from “just a” prototype to an industrialised solution is infinitely more complex that most people think. This is just as true in software as it is in manufacturing.
Just because you’ve managed to build a car in your garage with a few hammer strokes here and there that you can become Renault, with industrialised production, the same guarantees and its network of maintenance and repair partners!
Governance, beyond the first client
Beyond new feature development and the complexity of software scaling, a larger number of clients has multiple consequences on a project:
- How to keep the roadmap under control when a funding client dictates the features you develop rather than those you feel should be a priority for your product?
- What governance and who defines and guarantees the solution’s long-term vision?
- Who is responsible for project implementations?
- Who ensures that different user contexts are compatible and work properly?
- Who maintains and upgrades the technological baseware, which regularly requires major development work and update tools/paths?
- How do you evaluate feature details and their impact depending on implementations?
- Who guarantees old versions?
- Who decides and secures APIs, and interactions with other tools or partners?
- How do you gain and develop know-how and skills when teams and projects change all the time?
These questions – or rather the lack of a satisfactory answer to them – also illustrate the limits to the service-based open-source software development model and explain why most organisations who believe they can free themselves of software publishers to fulfil a standard need ultimately fail.
An open-source software publisher, what for?
A solution isn’t source code. It’s a reliable, supported, high-quality product people enjoy using, with reliable, transparent pricing.
The role of a software publisher is to design, maintain and enhance a lasting product that meets end users’ needs in terms of features, ergonomics and performance.
You don’t become a software publisher out of the blue. It requires long-term commitments, effective governance, significant vision, anticipation, development, quality and maintenance capabilities as well as an entire organisation to respond to clients’ and partners’ requests and needs for a solution!
Open-source publishers typically sell offerings that complement or facilitate a solution’s use and operation, for example with add-ons, extra features, support provided by “ultimate software experts” and guaranteed responsiveness. This includes subscriptions, a Software as a Service solution (providing the solution as a hosted service), freemium/open core additional modules or features, or other services.
These offerings are usually well thought-out and bring a good balance between value added and return. We find – in France specifically – clients who want a solution but not its publisher’s offering. They are even prepared to pay (a little) but want to outline the offering themselves! A classic example of software-publisher hostility translates as “I’m happy to pay for support but I don’t want to pay per user” – including when it is the fairest, most relevant and simple metric.
It’s a little like playing couch coach! Software publishers’ offerings are part of their business model, its readability and the equation as a whole. There is no point in trying to force them to redefine their offering – in particular by applying principles that don’t work, for example “financing the software through support” – it must be respected!
Working with an open-source publisher rather than trying to work around them means maximising your chances of success, having a better solution, ensuring the software’s continuity, enjoying the best expertise while saving money and promoting the open philosophy that ultimately benefits everyone.
Whether they’re a company, an NGO or a foundation, whether they are for profit or not, software publishers are the champions of the future of open-source solutions. They have an organisation, employees, a roadmap and financial challenges to face. Open-source software doesn’t live off thin air!
Open-source software publishing: BlueMind’s vision
One thing is for sure: complaining that there are too few quality open-source solutions for end users is in contradiction with harbouring hostility towards open-source software publishers!
For BlueMind, the path is clear: to be a true sovereign alternative to major US solutions, we must first and foremost have a good product! As far as email is concerned, having a good product means providing a well-grounded answer to four key market requirements:
- Features: Offering advanced mail features for the core of the email application. This isn’t just about checking boxes for email, calendar, and contact features, but about offering advanced use scenarios and a large functional scope that smoothly integrates other collaboration components (videoconferencing, documents, live communications, knowledge base, etc.).
- Habits: Email is the number one enterprise tool. More than any other tool, when it comes to email, users drive decisions, and this tends to lead to Outlook. BlueMind has been tackling this issue by putting users at the heart of every development step to become the only email that is “compatible with all uses”. This means native Outlook (BlueMind is the only alternative to Microsoft that has achieved the feat of supporting Outlook without a connector) but also any other means of access.
- Resilience and security: Email not only has to work but it also must never stop working!
- Scalability: To respond to all issues, evolutions, population growth and collaborative uses.
BlueMind’s open-source business model is what enables it to meet to all four requirements! Developing high-quality, lasting, user-centred software is what a software publisher does. And this cannot be achieved through a service-based model, including an open-source one.
Being a software publisher means that we are 100% focused on building our solution: the product and all the tools and resources around it, such as migration tools, documentation (technical, functional and commercial), as well as our ecosystem (integrators and technological partners, among others). The overall, long-term vision and governance we bring is what ensures our solution’s well-roundedness.
This is the level of quality end users expect and what enables BlueMind to offer a credible, sovereign alternative and most importantly, one that users and clients embrace!
#TheChoiceIsHere
