Is GitBook still alive?

[drobiazko]

Is it worth to consider GitBook? I have my doubts due to:

• it seems like there is nobody reading support emails. Even as a paying customer I'm being ignored.
• last blog post is now 4 months old
• last commit to this repo was done more than 2 moths ago
• last tweets is almost 2 moths old
• many issues are open since months without any comments
• many pull requests are waiting to be merged since months

Any ideas?

[nagim]

Hi,

Yes, it's still alive.
The lack of activity in the GitHub repo only shows that the work is currently being done in other repos that are not public.
The team is in the middle of a complete overhaul of the whole GitBook experience (that's why you didn't notice activity in the repos, as it will be a different approach compared to the existing one), which takes a lot of time and effort now. It is currently in beta testing phase, I believe.

I agree that a lack of response to support emails can be frustrating, I guess with this amount of work for a team of 5 or so people, support emails processing might be very slow.

I'm a paying customer as well and I often write to the Slack channel which often allows for speedier responses.

Cheers,
Imre

[drobiazko]

Thank you for your answer @nagim.

I understand your arguments about the new GitBook experience and the size of the team. However the guys behind GitBook need to learn how to handle customers. The only reason I purchased an organizational plan was Individual support. You can have the best product in the world but if you ignore your customers you will lose all of them. You just must not concentrate on delivering new version of your product without helping your paying customers.

[nagim]

Yes, you're right on this.
Again, try to contact them on Slack via a direct message. That usually works best for me.

[drobiazko]

I asked my questions on Slack as well. Unfortunately it was not answered either.

[nagim]

The one regarding variables? If you come online, I might be able to help.

[AaronO]

Hi @drobiazko,

First and foremost I am sorry if you've experienced delayed replies (could you email me at aaron@gitbook.com with the specific issues you need help with ?), I'm travelling at the moment but will get back to you when in a few hours when I'm back.

Secondly, GitBook is very much alive, we're beta testing a massive product release that solves many of the core product issues we gathered from users (by talking with users and running surveys).

I'm sorry you've encountered issues, email me or ping me on slack so I can help you with your immediate issues.

Kind Regards,
Aaron

[zuker]

Hmm, it's strange to make clients struggle to get paid support...

[melvinchng]

@AaronO I sent you an email regarding student discount. I have been trying to contact the team for more than a month now and I receive zero response.

[reviewher]

Anyone find an alternative to gitbook?

[pnicoll]

The team is in the middle of a complete overhaul of the whole GitBook experience

We find this troubling.

[AaronO]

@pnicoll It's important to highlight that we're doing this as a result of user-feedback:

... product release that solves many of the core product issues we gathered from users (by talking with users and running surveys).

We spent a lot of time talking with our users, to really understand the major pain points. We've been beta-testing the new-release with a few organizations over the past few weeks with solid feedback so far.

As a result here are some of the improvements currently implemented in the new release:

• Unified read & write experience (much much simpler UI/UX)
• Simple and clean company branding out of the box (branding is super-important for public product/API docs)
  • Upload a logo and pick a color (we automatically suggest one from your logo)
  • Set custom links in header
  • Header logo & favicon
  • It takes seconds not hours (no need to write CSS/HTML/JS or plugins ...)
• Editor now natively supports editing rich content (hints, embeds, api methods, ...), no longer requires a templating syntax !
• Most common / popular plugin-powered features are now implemented 1st party (non-exhaustive list):
  • Title anchors
  • Collapsible TOC entries
  • Image captions
  • Hints / Callouts
  • Rich embeds (to embed external content, e.g: YouTube videos)
  • And more ...
• Relevant & fast content-wide search (works on users and comments too !)

Overall things are an order of magnitude simpler, more reliable and less quirky.

@pnicoll I would love to talk one-on-one over Slack or Skype/Hangouts and hear your feedback (and potential concerns).

I've had a call with @drobiazko and am working with them to help streamline their docs (they have some special requirements that no documentation solution will solve out-of-the-box).

[pnicoll]

@AaronO That all sounds great, especially collapsible TOC entries (using a plug-in then clicking on a second-level TOC associated to an anchor link breaks the search entirely, which we told you about in January; see #1670, in particular @nagim 's comment @SamyPesse this issue is quite serious, basically you cannot use search if you have scrolled down in a page, because it crashes instantly). As a result, we can only have level 1 TOC entries, and some of our chapters are massive, so our users have to scroll or search instead of immediately finding what they're looking for in the TOC.

What worries us is what might be broken with this overhaul.

[AaronO]

@pnicoll The error you encountered is precisely a symptom of the underlaying problem that we're fixing (I'm sorry that you encountered it).

Namely that GitBook requires plugins for:

• Branding (a must-have for companies, which today have to painfully write custom HTML/CSS/...)
• Improvements (e.g: title-anchors, better search, etc ...), that should be built-in
• To include rich content (youtube videos, iframes, etc ...)
  However:
• Most plugins are developed by 3rd party devs, not the core gitbook team
• Plugins may conflict with one-another (or builtin plugins, such as the crash you saw)
• They require editing book.json or using a templating syntax (for end-users)
• Which isn't supported by the WYSIWYG editor (it would be impossible for us to provide a tailored editing experience for arbitrary 3rd-party plugins)
• May break your builds (and prevent your content from updating ... I hate that this is even possible ...)

Overall this exposes a lot of unnecessary complexity and technicalities that end-users (you guys) have to worry about, that's frustrating and a subpar UX.

The core focus of this release is building a much simpler (UI & UX) and reliable experience for our users. Everything a team needs to write their documentation should be simple, reliable and "just work"™. No build failures, plugin conflicts, sync errors, ...

I would love to jump on a call, understand your specific use-case & needs, demo you the beta so you can get a better understanding of where we're going (and see for yourself if it truly is simpler/better).

[AaronO]

We will announce the beta (through an official blog post) and have a landing page with more info very soon.

We wanted to have tangible results and feedback (from beta-testers) before announcing it.

[greatdreams]

Is there any latest developing information about gitbook and gitbook editor?

[FibreFoX]

@AaronO Don't want to be that picky, but how about writing some "CURRENTLY COMPLETE REWORK IN PROGRESS" inside the readme-file? This way you can communicate with non-slack users and github-only visitors.

It get's very annoying to not get response to issues like #1784, which blocks pull-requests for the current version, which makes this project seem to be dead.

[kozi]

We will announce the beta (through an official blog post) and have a landing page with more info very soon.

Can you say what very soon means?

[pnicoll]

It's been 29 days since we've heard from @AaronO, so "very soon" seems to mean nothing.

GitBook is still billing me, however.

[AaronO]

@kozi @pnicoll We'll be releasing a blog post and homepage for the new beta this week, where users will be able to request beta access (we're aiming for Friday but it might come out tomorrow, because we want to give everyone an update and showcase the new improvements and what we've been working on).

We've been working hard on the beta, you can see the release notes for the latest beta releases here: https://betadocs.gitbook.com/changelog

If you anyone has specific questions, or things they would like to see improved in GitBook (and thus tackled by this new release) I would love to jump on a quick call with them

(You can reach me at aaron@gitbook.com)

We've been working on this beta to solve the major key issues we heard from our users, a lot of which were non-trivial, if anyone in this thread has any issues please contact me directly.

---

I also followed up with Igor (@drobiazko) who originally started this thread, had a call with him regarding their use-case, which admittedly is a bit of an edge-case, so I explained a few approaches that would work.
Since it's unlikely that we'll implement 1st-class support for white-labelling a single project into multiple live projects, that share all their content but differ in branding and some URL rewriting.
My recommended approach was to write a small proxy service on their end that's aware of all the custom branding they want to do and uses our APIs to pull in the relevant content and rewrite it before rendering to the end-user. Allowing them to have full control over their white-labelling logic and have one simple repo of content to maintain.

[pnicoll]

@AaronO Thanks for the update.

What would be really nice would be the ability to set table column widths. Overriding with HTML (which I have to do in long cells that contain a combination of regular text and bulleted lists, for example) doesn't work, nor does forcing a column width with non-breaking spaces ( ) for different tables that have the same column headers. As a result, I have tables with the same headers but different-sized columns, which makes my documentation look sloppy.

[AaronO]

@pnicoll Writing custom HTML isn't a great solution, because it's fairly technical, fragile and a bad practice. I think what you're hitting here with tables is possibly a markdown limitation.

With this new version we can have smarter editing & rendering logic, to accommodate for those kind of situations.

We haven't yet done much work specifically on tables, because nobody has given us table-specific feedback so far.

I personally avoid putting too much content inside tables, and often opt for titles to group that content together. However, I don't know enough about your use-case to know if that makes sense for you.

Would love to jump on a quick call if you're free tomorrow or Friday to better understand your tables issue and see if we can fix it.

[nagim]

@AaronO I have sent you table-specific feedback/suggestions before, too. If it got lost somehow in the meantime, let me know, I will resend it.

[pnicoll]

@AaronO I understand that markdown tables are limited. If the smarter rendering logic can properly render non-breaking spaces to force column width (e.g. two tables with the same headers, so |Column header 1      |Column header 2| for both) then I'd be happy. Having different column widths for tables with the same headers makes it look like I don't care about formatting, when in fact it's the exact opposite.

Due to some of the content of my tables I often have to use HTML, and in markdown tables, everything in an <ol> or <ul> has to be in one line; there's no way around it, believe me, I've tried. So I end up with rows that look like this:

|Template|Selection of workflow templates to be tested directly, customizable and usable in the "By default" list or in the "library"<p></p><p>Default:</p><ul><li>2 levels approval</li><li>Parallel tasks</li><li>Simple approval</li><li>Simple request</li></ul><p>Library:</p><ul><li>Expense report</li><li>Software helpdesk</li><li>Investment application</li><li>IT Changes</li><li>IT Clearance application</li><li>Leave application</li><li>New Product Creation</li><li>Work Order</li></ul><p>A customized workflow template can be created and deployed on the server with the following folder and file structure:</p><p>\wfgen\App_Data\Templates\Processes\[language]\[folder name]\[process name]v[x].xml</p><p>Example:<p>\wfgen\App_Data\Templates\Processes \En\MyCompany\MY_PROCESSv1.xml</p><p>**Note:** Only processes with forms created with the built-in form designer can be used as workflow templates.|

This is all one row.

[AaronO]

@nagim Nope Imre, I've still got the feedback you sent me regarding table cells and the ability to merge cells.

@pnicoll Do you have a link to share so I can see what it looks like ? Would be great if you had an example of desired output in raw HTML, compared to our current output.

[AaronO]

@nagim @pnicoll Happy to talk more about tables, but we should probably move this conversation to https://github.com/GitbookIO/feedback, to not clutter this already long thread and go off-topic.

Would be great to have that feedback grouped into relevant issues (one on merged table-cells, another on alignment) with "current output/behavior" and "expected output/behavior" for each.

[lbeltrame]

@AaronO Given the beta links, and the fact that even the mentions do not say much about the toolchain, the question is: will the toolchain keep on being open source, or will it be irreversibly tied to gitbook.com? I use the toolchain for convenience, and would never consider it if I can't self host the content painlessly (note: the competition has a similar and equally questionable stance).

[AaronO]

@lbeltrame Sorry for the late reply, I was out of the office for a while following a medical operation.

In short: the toolchain will continue to exist in some form, but it needs to evolve.

Our goal is to enable teams to write great documentation (external API & Product docs, internal / team docs, ...). Everything else is a means to an end.

Samy and I built the first version of GitBook because we believed that documents should be simpler, smarter and richer.

We did not stop at building the toolchain because we knew that by itself it was only a small part of what teams need (editing, hosting, collaboration, ...).

Given that we're a small team with limited resources, we have to chose our battles.
I don't think it would help our users or the project to focus on "self-hosting", it would only increase fragmentation and complexity ...

We're committed to building a great product for our users (that's simple, reliable and powerful), we believe in open-source and will continue to contribute (we're not looking to vendor-lock anyone) and have exciting new tech and APIs that are radically better for devs than what we have today (plugins, templating syntax, ...).

If you believe that an open-source project diverges from your goals, you have the freedom to fork it.

[lbeltrame]

Basically, it's not going to be the focus, in some way, but you'll leave the toolchain open for others to improve, should the need arise.

That's fine, and I understand your needs. They simply do not align with mine (I'm using gitbook to write non-technical books, which are self-hosted), so I'll pick another tool (pandoc) with a different scope.

That said, thanks for your work on GitBook because it did help me when I started writing.

[kirtan403]

@AaronO That's really sad to here that, in some form the open toolchain will stop updating as you are focusing on building a product for consumer. Self hosting is one of the key factor which made gitbook popular, IMHO.

I just hope that toolchain will be in the focus again..

[develar]

Why I still use Gitbook instead of another static site generator — because without extra customisation you get really great documentation site. Just write docs and gitbook build. No need to tweak style, search another better default theme and so on.

The only problem now — anchors navigation doesn't work reliably (a lot of reports about it in this issue tracker). And I see that in the beta version it is fixed.

I totally understand, that my usage is out of your product scope — I edit docs using IDE and publish to Netlify. But as far I see, in any case for gitbook.com some tool should be used to convert md to html. Not clear for me — why beta gitbook theme / new generator is not developed here as beta version/branch. Why users cannot use (and test) beta version of new generator.

Anyway, still hope that in the next several months it will be updated. Thanks for a great product.

[Undistraction]

For anyone else looking for an alternative now that Gitbook has removed Markdown editing, corilla is pretty good and has a generous free plan. It's in Beta at the moment and has a few rough edges but does everything I need it to do.

[YoungJaeChoung]

@Undistraction

does corilla support latex syntax...?

[Undistraction]

@YoungJaeChoung I ended up ditching corilla and moving to notion.so which is exactly what I've been looking for for years. I can't recommend it enough. And it support LaTeX. It's the first thing I've used for ages which has really blown me away.

[yjchoung1]

@Undistraction Thank you for the information about a new site. I will try it. Thanks!!! x 100

[dskvr]

It's obvious Gitbook has gone in a different direction. They've completely nixed statically generated docs, as well as plugins and pretty much everything that made Gitbook good while also making their name "GitBook" completely irrelevant.

So shall we start an effort to fork, rename and maintain our beloved "Legacy" Gitbook?

[balhrog]

Fork that shit

[nreynis]

I agree Gitbook V2 and legacy Gitbook are two entirely different products, and most of the features that made me interested in it are gone in the new version.

[pnicoll]

All I wanted was a markdown pane, or at least to be able to toggle between WYSIWYG and markdown pages. Potential use case: Developer wants their now-properly-formatted .md code back for a readme. I copy the rendered WYSIWYG from the new GitBook. What will be pasted? I asked this a LONG time ago and never got an answer.

I can live without a desktop editor, and I figure most of our clients will read the documentation online, not generating PDFs, but I cannot work in a markdown-based editor that does not display markdown code.

[elvisbegovic]

@dskvr no dude you're wrong, they call that innovation, they call that you need your doc online hosted by them, they call that we are in best position to know best option we can't continue with hacky plugin while wordpress can...

[nreynis]

@dskvr You know people still got to make a living. If they wan't to push their product all the way on the SaaS road that's their call. The legacy version probably wasn't generating enough paying customers to sustain the company.

[morinted]

I was looking to replace my legacy gitbook site with some custom Gatsby or React-Static site, but just now I discovered Docusaurus.

Honestly, this is what I've always wished Gitbook was. Basically, it's got all the same major features (static site generation, pretty sidebar, mobile-view, markdown content) except it's written in React and lets you write custom components and the like as part of your docs. Perfect!

Only gripe: no PDF export.

[maksimyurkov]

I tried all of the above in the topic and other gitbook replacements. As a result, I transferred my book to VuePress. Highly recommend.

[dskvr]

@maksimyurkov I've been leaning towards VuePress.

@morinted Docusaurus looks good at first glance, but I'm not seeing an interactive API (like gitbook had and VuePress has) ... Only feature I'm seeing that's not natively supported by VuePress is Versioning.

[energyd]

simple question, how do I migrate all my docs from legacy to new gitbook? (or to any of the new ones you guys mentioned above, VuePress, etc..)

[ketozhang]

For VuePress or Docosaurus is there a way to simply use the directory stucture of my markdown files say all in docs/ to side nav.

A simple use case is a book where in docs/ you have directories for each chapter.

A more specific use case for myself is I have topics and subtopics within my book (it's a Markdown notebook).

[morinted]

When migrating to VuePress I had to redo my sidebar in config.js: https://vuepress.vuejs.org/default-theme-config/#sidebar There is documentation for "groups" and nav within the page. Good luck!

…

On Mon, Nov 5, 2018, 6:53 PM Keto Zhang ***@***.*** wrote: For VuePress or Docosaurus is there a way to simply use the directory stucture of my markdown files say all in docs/ to side nav. A simple use case is a book where in docs/ you have directories for each chapter. A more specific use case for myself is I have topics and subtopics within my book (it's a Markdown notebook). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1808 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFkgSrbQuET8RZp9doTl__zCGK4C_dolks5usM99gaJpZM4NyTg4> .

[oxr463]

Anyone find an alternative to gitbook?

There are plenty of other great static-site generators out there. I actually really liked the look of gitbooks, so much in fact, that I ported it to Mkdocs.

[dariushazimi]

I am getting this error when trying to login to gitbook client on macOS.

Any idea? Anyone, commented on the open issue on gitbook repo but I don't see any activity there at all.
Unauthorized New accounts should be created on the new version of GitBook. Head to https://www.gitbook.com

os: macOS Mojave
git version 2.19.0
Created a new account on gitbook.com site.
Logged in successfully on gitbook.com
downloaded the client.
Can't login.
Tried to login with github and google but both have the same issue.

401 Unauthorized New accounts should be created on the new version of GitBook. Head to https://www.gitbook.com

#2119

Unauthorized New accounts should be created on the new version of GitBook. Head to https://www.gitbook.com

[SteveBenner]

I normally wouldn't go out of my way to comment on something like this, but right now I'm simply flabbergasted. I was using Gitbook a few years back and it was great. I was just now going to recommend Gitbook to a friend as an analogous solution to Flatdoc, but upon visiting their site again my confusion just gave way to sadness and vexation.

The question 'is Gitbook still alive?' should, I think, be answered as a definitive NO. This new platform is entirely incomparable to the original software, and yet heralded as 'version 2' somehow. Reading through the list of 'important changes' from the original, it became clear they had literally removed all of the features I had found unique, useful, and delightful software to begin with.

As a user, I'm not upset at them for changing--there are plenty of other solutions out there, and I have nothing against a team wanting to monetize their creation. This transformation has been completely misleading, though--I don't see how anyone can call the new platform 'version 2' of the original Gitbook when it is nothing of the sort. This is why rebranding exists. The original creation should have been rebranded, seeing as it is now an entirely different platform.

On their site they say:

Today we empower teams of all sizes to build great internal & external docs

Yet no one is going to be empowered if they, like me, are uninterested in the new platform.

P.S. I gave AaronO a thumb up to his latest response because he is being totally reasonable, and his point is correct - we can fork it if we want to keep the original project alive. My distaste is only in the business decision to not diverge from the original creation, in branding.

[piranna]

So, @SteveBenner... maybe is it time to create a fork, like Mate Desktop did with Gnome 2? :-)

[SteveBenner]

So, @SteveBenner... maybe is it time to create a fork, like Mate Desktop did with Gnome 2? :-)

Yes.

[piranna]

Count with me.

[SamyPesse]

@piranna @SteveBenner I understand your position, but I'm locking this issue as it's not bringing any value (on either side).

The code source for the legacy CLI is and will always be available on GitHub.
The new GitBook.com has a compatibility with it using our GitHub sync and brings many large improvements that were not possible with the CLI.

We'll continue focusing our efforts in building the best documentation platform for all teams with GitBook.com.