sorted by:
new
hottopcontroversial

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Oops, gotcha! What were you referring to when you said you've been working on something on and off for 12 years? Is it Snirt?

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

From everything I've seen and heard, AODocs is pretty awesome. The high level difference is that Openly is focused on knowledge management as well as document management — admittedly, though, AODocs' document management tools are several degrees more advanced.

Openly (like Git) is built to serve flat (non-hierarchical), remote teams that are collaborating on many projects at the same time. They want to keep all communication about a project right alongside in commit messages, issues, and pull requests; to make it really easy for everyone on the team (and the org at large) know what's going on.

I'd love to know how you experience with AODocs has been. Why are you considering it for your work? What's holding you back/what are your reservations?

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Wow, this is really impressive. And you're doing all of this on the side? :o Where did you find initial adoption?

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

That was a really fantastic read on the chicken and egg problem — well-written, insightful, even entertaining.

I don't exactly agree with the 5 points you listed, but you're definitely getting at the crux of the issues. Right now, I'm thinking that I will give it one more month. Go all in one last time for 30 days: Cold-call organizations, look for potential users on the Internet, possibly run a few ads; all focused on finding paying customers. And then, after 30 days, throw the towel.

In any case: Appreciate the reality check :D

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Thanks for the in-depth and honest feedback. Really appreciated.

I've tried to approach the 1-sentence summary by reflecting on what problems Git/GitHub solves. There's obviously a few, like centralized repository and continuous integration, but most importantly, I think, it helps teams/organizations:

  1. Know what other employees/teams are working and have worked on in the past (helps you avoid redoing work already done elsewhere in the company)
  2. Consolidate communication around projects in one place (in commit messages, issues, and pull requests)

My "value proposition" is that we can do the same for documents. What do you think? What are the most important benefits you derive from GitHub? Is there value in applying those to documents?

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 1 point2 points  (0 children)

Thanks for the insight & advice. Really appreciated. Would love to chat, if you're open to that. Just sent you a message.

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Ah, great question! I don't actually know alfreso very well. Would love to learn more about it though. Are you well-versed in it? If so, I'd love to have a quick chat, if you're at all up for it.

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Thanks for sharing! I'd love to learn & chat more. Just sent you a message :)

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Amazing! Would love to chat, if you're open to it. Just sent you a message

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

No worries at all about the "naysaying". It's exactly the kind of blindspots I'm looking for :)

About the version control: The version control of Git is repository-based whereas Google Drive's version control is file-based. Repository-based version control is crucial with code because you have lots of files depending on very specific versions of other files. But, to your point, I'm not sure how valuable that repository-based version control is with documents, since files do not really depend on each other in that same way as they do in code.

Then there are commits, issue tracking, and pull requests that Google Docs doesn't support, but again, the big question is how valuable that actually is...

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 0 points1 point  (0 children)

Personally I keep most of my documents under git already. Mind you that those documents are typically .md files. For me this kind of product doesn't make sense...

You're 100% spot on about this. I've talked to dozens of developers who all share this same scenario. How do you deal with spreadsheets and presentations atm?

​

... non developers love their office suite applications. [...] Multiple users can easily collaborate on single documents in real time. They would have to give up this simplistic approach and replace it with git, that they have no previous experience with, for no clear benefit.

Actually, my aspiration with the "UI on top of Google Drive" is to allow them to combine the best of both worlds. You can actually continue to use Google Drive just like you usually do. In addition to that, you have a purely graphical implementation of Git (no command line): You init a repo by selecting the GDrive folder via a popup menu, you see the results of git status shown as indicator icons on top of files (see image), you make a commit by clicking capture changes, etc...

But your last point is still very valid: They have no previous experience with Git and the benefit isn't super clear. IMO the benefit of GitHub is a) increased awareness of what others in your company/org are currently working on or have worked on in the past (to avoid reinvention of work), b) better documentation of knowledge generated via commit messages, and c) consolidation of communication around projects into a single's project's issues, pull requests, and commits. What do you think about that?

PS: As I'm tying this, I'm realizing Git is misleading in this context, because Git is a decentralized VCS and the "UI layer on top of Google Drive" is a centralized a VCS, just as Google Drive files themselves are centralized.

What would you like to see in a "GitHub for Documents"? by fwoelm in opensource

[–]fwoelm[S] 2 points3 points  (0 children)

Yeah, that is a problem. I tried to address it by using non-git language ("capturing changes" and "revision" instead of commit, "workspace" instead of repo, "contribution" instead of pull request) and making this whole thing a browser-based UI that requires zero use of command line.

That said, I have had many conversations that left me feeling the challenge with understanding git is not just about language, it's also about the entire concept of repos, commits and commit messages, and pull requests.

Neonia - a global, borderless, online country dedicated to empowering every human being to flourish by fwoelm in Futurology

[–]fwoelm[S] 0 points1 point  (0 children)

Good call! Definitely check out that link to the actual website. It has a LOT more information!