At Homeville, when we started active product development, JIRA and Confluence were our go to tools. As the technology team grew from a 4 member team to a 65+ member team, one of the things that became a slow burn for me was to see the monthly user-wise licensing model for both of these tools.
JIRA was free for the first 10 users, then for the next 40 odd users that we added, we were paying roughly 400 USD per month! Similarily, Confluence was free for the first 10 users, but at a team of 40 or so, our bills from Atlassian was matching our bills from AWS!
Shifting from Atlassian
One of the quickest shifts we did was to find an open source self hosted version of JIRA. OpenProject was the perfect solution. The benefit of self hosting these systems was that access to all the proprietary analysis and research in the form of features and requirements was now within our AWS account and thus in a much more secure environment. The added benefit of localization within the country also meant any form of regulatory compliance was also much better aligned.
It took some scripting, but using a python script to connect to JIRA and OpenProject (OP) both, we were able to import the projects, tickets and sprint informations from JIRA to OP.
Wiki or independent system
One of the key decision that we had to undertake was to see if the documentation was to be done within the OP, or was it to be hosted separately? One option was to continue with Confluence albeit under a smaller user base.
We finally decided to try things with a self-hosted WordPress. However, we did tweak quite a lot of things, listing all of these.
Customizing WordPress
Going into this project, I knew that this would be a continuous evaluation and test work. Sort of a rinse and repeat exercise. Hence, choosing WordPress was the obvious choice.
Custom Taxonomies
We setup PODs because of its ability to quickly add custom post types, custom taxonomies and easy relationships between the two. Using this we could easily keep a separate taxonomy for our credit platforms and systems.
Authorization and Access
Since we were on Microsoft o365, we setup an active directory plugin to enable tech team users to login using their o365 credentials. This also seamlessly created their user ids on WordPress and enabled access without the trouble of invites and importing users.
We also wanted a login gate to enable authorized access to our content. Thus a simple membership plugin to restrict content access was setup.
Similarly, we also setup a plugin that disabled the REST API so that the content wasnt available over unauthorized REST API calls.
We also setup a NACL rule on our AWS to prevent access to the system outside the office premises.
Integration with OpenProject
We also setup easy shortcodes that would pull data from OpenProject agile sprints and display those within a post, allowing for product teams to create east release notes followed by the sprint backlog with links to the OpenProject stories.
This was done using a custom plugin integration that we wrote. Obviously this could not have been possible without OP not having a REST API.
Document Templates FTW
This entire process would not have been successful without the new WordPress editor and its ability to create document template types within the post.
We took our most commonly used Confluence templates and set them up exactly in the same manner in WordPress. This enabled our product teams to seamless shift from Confluence to WordPress.
The fact that most discussions can also be captured as minutes with the exact time of publishing as the time when the meeting occurred also meant that we could also have a temporal view of our product development.
Thus with these simple and easy tweaks we shifted from Confluence to a self hosted WordPress.
