We developed an analogue of Confluence. What came out of it and why we did not invest 10 million rubles in the product
Hi, I'm Vyacheslav, the head of marketing at ispmanager. We're creating a complex software product that requires documentation. We used Confluence, but decided to change the software — even before Atlassian left Russia.
I'll tell you why we decided to migrate, what alternatives we tested, how we launched our own analogue and didn't fall into the “product abyss”. I'll also share what didn't go according to plan and why we abandoned the idea of promoting the product on a commercial basis.
Migrate, you can't stay
A popular reason for migrating from Confluence is the difficulty with payment after Atlassian left the Russian market. We had no problems with this, but there were other requests – Atlassian's departure added motivation to make a decision on migration faster =)
We sell a control panel — a fairly narrow niche. There are few SEO queries — most of them are related to hosting services, which we do not provide. Therefore, the semantic core is small — we wanted to expand it by indexing pages with documentation.
Why we decided to migrate from Confluence:
Technical difficulties due to Atlassian's departure from Russia — we couldn’t add a subdomain in the .ru zone to the application — the design rudocs.ispmanager.com instead of the usual docs.ispmanager.ru didn’t suit us.
The need to expand the semantic core. The articles on the subdomain “hide” SEO keys – we planned to use them to expand the semantic core. Therefore, the task was to transfer the content to the host – so that the documentation was on the same server with the site, and it had the address example.com/doc instead of doc.example.com. This could not be done with Confluence – it can only be placed on a subdomain.
We choose a ready-made solution
We have compiled a list of requirements from the team, what we need from a Confluence analogue:
Installation on the host is the main requirement.
Convenient migration from Confluence without losing content.
Clear article editor – Markdown markup language, inline styles. For example, text highlighting, italics, lists.
Ability to work with the structure of articles – change levels and work with the article tree.
At the beginning of 2022, several domestic options were available – we tried different ones. For example, we tested EvaWiki – the application worked slowly, pages took a long time to load. DevOps did not approve – EvaWiki's architecture at that time was “monolithic”, this threatened us with a large load on the server and slow website operation.
Common Problem with Confluence Analogs — The software does not support installation on the host or there is a difficult migration and data was lost during the “move”. |
We looked at the market and realized that it was time to make our product. Large companies had already done this – for example, Yandex launched Yandex Wiki, Rostelecom – the project management system “Yaga”. We got to work.
Let's do it like in Confluence
We have experience in creating web applications – ispmanager is already working on the website feature request and forumwhich we wrote from scratch based on open-source solutions.
The following technologies were taken as a basis:
Laravel framework for websites and web applications.
Admin panel based on Orchid – Open-source solution for the administrative part of the site.
MySQL (MariaDB) for databases.
Next to the feature request on the host, we had an up-to-date Drupal site — we were planning to place the documentation there as well. We were looking for an architecture for this “zoo” that would be able to work properly.
While we were discussing the future architecture, the designer was developing the look of the documentation — there were the fewest problems here. As part of the rebranding, we were already updating everything on the site. Therefore, the documentation design was approved before the developers sat down to write the backend. The Confluence design served as a reference.
We code, release and roll into the product abyss
Five of us started working: me, two web developers, DevOps and a designer. A tester joined later.
They didn’t think long about the name of the product, they started from the recognizable brand ispmanager – it turned out to be ispmanager Docs, and within the company the abbreviation iDocs took root.
What the work process looked like before the first deployment:
Wrote a parser for Confluence and dumped a space dump from Confluence into it — lost half of the content in the process. Spent a few more days — finished the parser, migrated the text, but lost the pictures. Confluence stores images in its database or pulls them from URL — had to “transport” the pictures to S3 storage and pull them from there by substituting the URL by mask.
We made the administrative part of the application — set up article creation, statuses, role-based access system, editor. We used open-source, but everything had to be put together and adjusted to our needs.
We developed the site architecture and configured the routingFor example, a user would land on a website and be redirected to the desired section, which was determined by the backend.
Launched rollout of updates using CI/CD — We didn't have it before. Over time, we learned to roll out individual elements of the system: docs, community, main site.
Cleaning up the aftermath of the deployment
What problems did we encounter after deployment:
The pages returned a 404 error. We were leaving the subdomain for the host, so it was important to set up redirects. It turned out we didn't do it well enough – about 20% of redirects were set up according to the mask rudocs.ispmanager.com/* let's go on the beard didn't put it down.
The reason was found in the parser when old and new URLs were compared – it changed the generation of Russian words in the English layout and “pol-zovatelya” turned into “polzovatelya”.
As a result, we found the old URL structure and set up redirects at the documentation level — we provided the ability to set up a 301 redirect from the iDocs interface. Transliteration was ultimately done the same way as it was in Confluence.
Everything was fixed in about a week, and as a result, iDocs was taught to collect URLs after parsing, just like Confluence does.
The error “Search not working” appeared – The search worked only by the article title and its description. Because of this, the representativeness of the results tended to zero.
In addition, the search turned out to be very overloaded. And the articles were given out by the degree of coincidence, not relevance. Therefore, old materials on outdated versions of the product stubbornly climbed to the top lines of the search results.
The designer and web developer completed the search, improved relevance and tweaked the interface. It became possible to choose which spaces to search — for example, root directories with ispmanager 6 documentation, SSL certificates and others.
What does the search by spaces look like:
After the first deployment of iDocs, we quickly realized that the product was raw – there was still a lot of work to be done, colleagues confirmed this =))
What else has been improved in iDocs:
We've tweaked the work with articles – added article previews, fixed errors that prevented text from being saved in blocks and code from being displayed correctly.
Added the ability to migrate from Confluence via API. Now you don't need to make a dump and load it into the parser — iDocs pulls everything via API.
Made a global change log.
What happened
iDocs design is made in light and dark themes. In the article told how they had already developed a dark theme for the ispmanager panel.
What does the iDocs user interface look like:
What iDocs looks like in the admin panel:
We tried to make an intuitively simple interface – now iDocs has a clear structure of articles by levels and convenient tools for design.
What the tools look like:
We made an automatic table of contents inside the article, which is pulled in via headers.
What does the table of contents look like inside articles:
We continue to take into account the team's wishes – we are finalizing the functionality that is needed in the work. For example, we added the ability to view the history of changes to an article:
results
We made a full-fledged product for documentation and knowledge base – it turned out to be a worthy alternative to Confluence, which we were able to host.
Killer feature of iDocs — the ability to install software on a host so that the documentation and the site are on the same server. As far as we know, Russian analogues of Confluence cannot boast of this — if you know any options, tell us about them in the comments. |
The goal of developing iDocs is to expand the semantic core by indexing pages with documentation on the main domain.
How ispmanager website traffic has changed:
The “move” to iDocs in May 2023 increased the traffic of the ispmanager website almost 2 times – now search engines show documentation to users more often, and this helps to increase SEO traffic. |
Why didn't they invest money in the development of iDocs
Initially, we wrote the product for ourselves — there was no goal to develop iDocs on a commercial basis. Later, we wanted to try to bring it to market. But it didn’t work out.
Why did you decide not to promote iDocs:
Small market – difficult to calculate the volume. Many large companies have already made similar solutions for themselves, and small players use free programs – for example, Media.Wiki, Wiki.js, DokuWiki.
Competition in the foreign market – it is difficult to “fight” with Confluence.
Costs — to start selling iDocs, you need to invest about 10 million rubles in the product. The budget includes the following tasks: develop mechanisms for updating client installations and accounting for the license term, close the code, organize technical support, simplify software installation, conduct custom developments with the audience.
Long payback period — the budget for entering the market is relatively small, but the payback period is more than 3 years. In the current economic situation, this does not seem like a reasonable investment — there are ways to recoup this amount faster. For example, expand the sales geography of the flagship product — the ispmanager control panel.
It is important for the company to develop a product with a clear market and payback period, so we abandoned the idea of promoting iDocs “to the people”.
But the development of iDocs did not stop there — we continued working and regularly tweak features for internal needs. Despite the fact that we made the product for ourselves, our partners have already bought it =)
If you have similar tasks and need an alternative to Confluence, write to the mail bizdev@ispmanager.comwe will help you deploy a documentation or knowledge base for your project. |
I don't consider the project a failure – iDocs completely satisfied ispmanager's need for documentation and knowledge base software. And thanks to our partners, we recouped the costs of the initial development.
Besides, we deliberately did not let the project slide into the “product abyss” – first we studied the demand, made calculations and decided not to enter the market. All in a grown-up way =)
If you already use your own or ready-made analogs of Confluence, share your impressions, we will discuss in the comments.
