Anyone using Flare for an open-source docs project?

[ghillerson]

I've been asked to look into how to best manage documentation for an open source database project. I've not yet had time to give it much thought, and I'm wondering if anyone is using Flare for such a purpose?

[RamonS]

I currently do not, but I plan to...depending if that open source project picks up some traction. The only concern I would have is that the sources need a proprietary tool to craft the output. That might be in conflict with the licensing and / or the project rules. Only the compiler (Flare) is proprietary, the source files are not and neither are most of the output formats (the only proprietary might be .NET help).

[Rona Kwestel]

Any updates on this?

We're preparing to open source some of our code, and while our general product docs are currently in Flare, it seems like the wrong tool for the open source doc content. We've started down the path with Sphinx, but also considering Jekyll or Hugo. Is anyone maintaining content in both Flare for internally maintained doc and one of these other tools for open source doc?

[RamonS]

Why is it the wrong tool? Use the best tool for the job. I do appreciate the keep things clean as far as open source goes, but don't let that get in the way of delivering great documentation for your users. Be one of the few FOSS projects where docs are not total crap (some still think that every user has an MS in computer science). I am sure you'd get some comments on not using a FOSS tool, but the sole point of FOSS is providing better and more affordable software than what is commercially available. Flare comes with a cost, but as far as help authoring goes, I can't think of a better tool to use.

[Rona Kwestel]

Interesting perspective, RamonS, but if you use Flare for the doc and none of your user community has access to or is willing to pay for Flare, how do you include them in the workflow of updating the documentation when they make updates to the corresponding OSS?

[RamonS]

Fair point, but the doc team could accept change requests and work those in. Many FOSS projects have a team of stewards that make sure that whatever gets submitted is not some junk that breaks a lot of other things. As I said, the goal is to provide better software with decent documentation. The rejection of closed source tools in the FOSS arena is at times a hindrance. This would be different if there are FOSS tools that are on par or near to Flare. I don't know of any.

[teknikulriter]

Any updates on this? Five years later, and we are trying to determine (several Flare updates later) if this is a good tool to use. The doc team should not be responsible for updating open source-type docs (the URL and JSON APIs will not be made public). Right?

[Rona Kwestel]

We never did open-source our code, so for now, we're still just using Flare for our own product documentation, and while no tool is perfect, I do find it the most powerful and flexible tool to use, and well worth the cost.