Is this Project Abandoned?

[iwelch]

It seems to be the central focus of the fountain markup language, which is not exactly a great development.

[shaedrich]

Unfortunately, it seems like it. Many interesting suggestions have been made in the issues, yet radio silence from @nyousefi

btw, a similar question had been asked under #40

[iwelch]

I dropped a suggestion to the pandoc author on jgm/pandoc#10097. if pandoc had a decent reader implementation, fountain.io would then (hopefully) deprecate away. the wrong number-of-lines-per-page is killing it for me. and swift or objective-c as a reference implementation doesn't strike me as ideal, anyway. a fountain->html would be the right reference implementation.

[shaedrich]

It seems to be the central focus of the fountain markup language, which is not exactly a great development.

What would be a better focus in your opinion?

[iwelch]

anything that is still being developed. pandoc is very prominent and active. JGM dedicates a lot of time to it.

[AssetsCamaroes]

I think @nyousefi is more active on more commercial projects like Highland2 : https://highland2.app/help/highland-document-format/

[twinsant]

Never mind. let's fork it.

[KevinQuisquater]

I’m also very interested in this, since I’m considering using Fountain to replace our current system. I’d rather avoid teaching users a new format if the project is effectively abandoned.

Do you think Fountain itself may have reached a stable enough point that it no longer really needs changes, or is that not a good way to think about it?

Have the original maintainers shown any interest in letting other people take over maintenance?

If not, is there a popular fork that the community now treats as the main continuation of the project?

Thanks a lot, and thanks to the creators and contributors for the amazing work.

[shaedrich]

Fountain itself is primarily just a syntax that doesn't require maintenance and will work indefinitely as long as tooling (e.g. Fountain to PDF) supports this format.

[KevinQuisquater]

Thanks Sebastian, sorry if my earlier comment was not phrased well, I am indeed asking about the markup syntax itself: is Fountain still expected to evolve?

My concern is the same one that was raised here in 2024 and does not seem to have received a definitive answer: there are interesting proposals in this repo, including some of the ones you mentioned earlier, and if Fountain is now considered "done", each app will end up extending it privately whenever it needs to support common script patterns or constructs, present or future, that are not covered by Fountain.

We could do that too and maintain our own fork, but we would much rather contribute to a shared community effort that keeps Fountain evolving for everyone, while always staying aligned with its original principles of simplicity and human readability.

So for app developers considering switching to Fountain in 2026 and beyond, 11 years after the last changes to the syntax, some interesting questions are:

• Is Fountain intentionally a fixed language now, with no expectation of further evolution?
• If so, is that because it is considered expressive enough for everything that can remain human-readable, and that anything beyond that would necessarily push the syntax in a more technical direction?
• Or, if that is not the reason and the original maintainers are simply no longer interested in or available for that role, is there interest in the community for a fork or successor project that would continue evolving the format while remaining backward compatible with original Fountain?

Thanks a lot.
This is mostly out of curiosity and before taking the decision, but if there are no clear answers on those topics, that is totally fine too! We will find a solution if we end up going with Fountain and realize it is missing some constructs for patterns commonly found in the scripts our users upload.

[shaedrich]

Yeah, I wondered about that, too. Fountain is great, but limited. From what I've seen, I don't expected it to be extended further. A fork might be interesting but a lot of work and people have to accept it as a successor.

[jiakuan]

Perhaps it's good idea to separate the spec from implementations.