Atlassian's abandonment of technical publication and help authoring as a key use case for Confluence is nothing new: 5 years ago they admitted it (CONFCLOUD-2522), and it explains our excruciating experience of being pushed onto a new Cloud editor that lacked critical functionality (50+ issues being tracked) that we rely on to author and produce our documentation.
Suppose that the economics of their market strategy are sound, and we're just not worth the development burden. What then? especially as our shops keep tight to the Atlassian stack?
Atlassian is becoming an enterprise platform that, in its broadening focus, needs considerable configuration with add-ons to fit any given organization -- much like Salesforce. And that comparison may suggest a path for us.
In 2008, the nonprofit community trying to use Salesforce started working together on the first version of NPSP, the Nonprofit Starter Pack, an open-source project to build out essential CRM functionality that most nonprofits need. It handles technical support via community-based forums and knowledge bases called Power of Us. All NPSP custom applications sit on top of the core Salesforce platform and evolve with it, all while being quite distinct from Salesforce's core mission of commercial B2B sales. Its separation from Salesforce is, I think, key to its unique success.
So, if technical publication is too niche a sector for Atlassian, yet we technical writers have a well-known set of common needs, could we not start a community to make this platform work for us? Could we have our own bundle of integrated add-ons that cover our needs for document control, version control, export design and automation, and more?
Confluence has always had add-on vendors who each cover portions of the tech pubs use case; premiere among them has been K15t. But the nature of Atlassian licensing has meant that the cost of assembling a huge collection of these needed add-ons is cost-prohibitive in most shops, end of story. It will never be the case that specialty tech pubs add-ons would or should be in the hands of most members of the organization, so pricing just never makes sense. My Support folks writing kbase articles use none of the power features that I do.
But what if we approached this as a community? What if we could license the bundle as a community member? What if the community entity licensed Data Center and enabled all the tech pubs add-ons, and we community members could pay for just the spaces and usage we incur from that shared whole? What if interested organizations could sponsor development on the add-ons and automation they most need, such as for translation control or exporting to LaTex? What if vendors such as K15t worked directly with the formal community of tech pubs users, which operated its own community-based forums and resources?
What if we each didn't have to go it alone?
Hey Mary,
Thanks for the shout out and we let me assure you that we do feel your pain and the pain of all people writing technical communication in Confluence.
When K15t was founded in 2009, our claim was "Tools for wiki-based documentation", and that's what we still do: We are here to make sure that Confluence is the best platform it can be to manage and publish technical communication.
The pricing topic you bring up is a difficult one: In order to build a sustainable business, we do need to charge for our Apps – to develop, to maintain, to support them. Yet we understand the budget constraints of many tech writers.
Unfortunately, the solution you've mentioned with a shared Data Center instance is not possible due to Atlassian's licensing restrictions.
But: Have you considered creating your own Confluence instances? That is particular simple with Confluence Cloud. That said: Some of the functionality is already supported by our next-gen content management app Scroll Documents. Also, Scroll Viewport allows to convert a Confluence space into a help site in minutes (more info: https://www.k15t.com/software/scroll-viewport)
Hope this helps,
-Stefan (Co-Founder and CEO of K15t)
PS: In some cases we can provide discounts for our Apps. Reach out to our support, they will check what is possible.
Posted by: Skleinei | November 23, 2020 at 11:49 AM
The link should be:
https://www.k15t.com/software/scroll-viewport
Posted by: Skleinei | November 23, 2020 at 11:53 AM
Thank you, Stefan! I have considered my own instance, but I see problems with how collaboration would work. As for Viewport, my blocker is that we publish into Jira Service Desk and need to SSO our customers coming in through that portal. Keep me in mind if you need beta testers for anything touching JSD. :-)
Posted by: Mary Connor | November 23, 2020 at 01:19 PM