I think this is a great idea! However, instead of starting with the technology, could we start with the user needs?

For example, although I try and run as much FLOSS stuff as possible, my current sticking points are:

1. Calendar
2. Group (workplace) chat
3. Kanban-style to-do boards

Personally, I'd like to see a Sandstorm instance for social.coop but, again, let's start with what people want/need!

Indeed, starting with members' needs is a good approach! Definitely feel free to comment with a type of service you need rather than a specific software.

This also brings up the question: what is social.coop's mission? Do we want to help members to "de-googlify" ourselves and go for a full suite of alternative web apps, or do we take the "social" in our name more literally and focus on social networking?...

How about we start a poll (which allows members to add options) for 2-3 weeks - start with your suggested types of software and let people add (I hadn't thought of Kanban - I use Trello all the time, would be great to migrate off it!).

I think starting we needs is the way to go.

Great opening thread by the way @mayel !

I'd start with the 'co-op' part of our name and focus on technologies for co-operation :)

I would echo Doug's comments almost verbatim. The top priority should be allowing people to communicate and coordinate. I'd love to have a social.coop email address!

However, in the interest of undermining my own point, the one specific capacity I was looking for and didn't see was some kind of online LaTeX service. I've been thinking for a while that the way to break the .doc and .docx stranglehold on documents may not be LibreOffice, but rather, ditching the word-processing paradigm entirely.

I personally like using Markdown for basic word processing (check out hackmd) but LaTeX could be worth having too (I wonder how many people use it? is it mostly in Academia?) I'll add it to the list! Fortunately there's ShareLaTeX which looks like a very mature project (with collaboration built in)

Yeah, I do an awful lot with markdown, too, which is why I suggested to @horatiotrobinson that he include gitit. That lets you go straight from markdown to PDF, via LaTeX, with the click of a mouse. But, it's written in Haskell, which doesn't integrate nicely with Ruby. And more to the point, some folks will need more fine-grained detail, which only LaTeX itself can give.

Hey @steve7!

(posting this updated version here because I had only discussed this topic briefly on Mastodon, and microblogging streams are difficult to track and piece ideas together)

I did take a look at gitit, and it's probably an excellent tool for personal use. However from the point of view of the org when you're offering a service for a number of users, technical ability of staff being capable of maintaining the software is a rather important concern. gitit is written in Haskell, which is a very interesting and powerful functional programming language. However, Haskell is also not the most popular of programming languages, Haskell is not the easiest code to read for 90%+ of mortal programmers who are used to imperative programming languages, and competent Haskell talent is scarce to come by. All that means that however good the software may be, it may be too hard or too costly to maintain (in terms of either money or person power) when compared to other available solutions. Thankfully, a number of other very decent potential FOSS solutions exist that are less costly to maintain, more familiar to the average programmer, and more compatible with the tools that Social.coop already has in place.

For example, I had suggested taking a look at a Gollum-rails wiki package, which is written in Ruby and available under the AGPL 3.0 licence.
Turns out that two services that social.coop already uses -namely Mastodon and Loomio- are also written in Ruby (using the Ruby on Rails framework) and are also available under the AGPL 3.0 licence.

Additionally, the Gollum-rails package is a glue package that allows for using the Gollum wiki tool. Gollum is very mature, well understood software that powers the wiki tools at Github, used by millions of their users daily.

All of which means that those three tools are not only the least costly to use and maintain, they also present the least of technical integration problems, and the least legal compatibility problems. (exactly zero legal compatibility problems to boot)

It would be interesting if others could take a look at these things and verify that I'm not overlooking something. But in my mind, unless somebody comes up with something astonishingly better, it's a pretty straightforward situation.

Yeah, the Haskell part is too bad. Gollum compares quite well to gitit, with one notable exception: it doesn't export to PDF. That's not a dealbreaker, but it is disappointing. Now, I did discover a Ruby wrapper for pandoc, alphabetum (not to be confused with the font of the same name), that might allow Gollum to do just that. I don't know how hard that would be.

Of course, it's also possible I'm the only one who cares about exporting to PDF, and everyone just wants a wiki to be a wiki.

Exporting to PDF is a perfectly reasonable need and a function that I'm sure many users would like to have. It's also fortunately a function that's very easy to add to any other Wiki, and there are a number of ways of exporting to PDF independently of the Wiki engine of choice. Take for example gitprint, which takes Github-flavoured markdown as input and generates clean PDF output from that.

https://gitprint.com/jquery/jquery/blob/master/README.md

If your work requires a different type of input or output formatting that can probably be worked on as well.