revitalise the open company initiative

[nobodxbodon]

Based on @waldyrious #175 (comment) and @balupton #175 (comment), shall we first have an evaluation of OCI's current status, and share our vision about its future, then get on the same page about short/long term goals?

Speaking for myself, my knowledge about OCI was mainly from opencompany/awesome-open-company#25. My understanding is that OCI maintains two platforms, www.opencompany.org website and open company list. Both seem to need more updating.

With the current open companies in the list, IMO OCI can be connected with them more, improve sharing and communication among the open company community, connect the open companies with the other awesome-open communities, and hopefully become an open company soon so that OCI can be on the exact same boat with them.

[waldyrious]

Thanks for launching this conversation, @nobodxbodon. I think the main issue with OCI is lack of manpower to keep things running. There are lots of moving pieces that need maintaining -- the website, the social media accounts, the github repos, the new Liberapay team, and probably more.

#166 (and #164 before it) provides a good summary of these, as well as some background regarding the route to the current status. At that time, @galuszkak, @tenkabuto and I attempted to wrap up the loose ends and get the project into a sustainable state (see some of the discussion in #168, for example), but we quickly lost steam and the project has been pretty much dormant since then.

As I initially suggested in #164, I think our best bet is to make the project as self-running as possible, by abandoning direct coordination with companies via the website pledges, and instead relying on collaborative curation of a list based on well-defined criteria that anyone can follow. Then it can grow from there, scaling in tandem with the community.

I understand that this is not as sexy or ambitious as rekindling the original OCI, or even making OCI into a proper company; but unless there are actually people interested in (and able to) work in part or full time in this project, I don't think it's realistic to pursue those dreams for the time being.

[nobodxbodon]

@waldyrious thanks for the background introduction.

I think our best bet is to make the project as self-running as possible

It makes sense to me.

abandoning direct coordination with companies via the website pledges

Do you mean auto-updating company directory on website based on the awesome-open-company list?

lots of moving pieces that need maintaining -- the website, the social media accounts

Could we utilize some services from the open company community, like using Buffer to simplify social media account management? Besides, how feasible is it to outsource the website developing work (auto-updating/redesign/SEO, etc) to some open company in the awesome-open-company list?

[galuszkak]

So mostly because lack of my time, I didn't reupdate TravisCI to make people do the changes and deploy them automatically when merged to master.

I will try to push this over the weekend, as I promised this last year ago and never had a chance to do that (and it's nothing that much complicated). So we can have a starting point that people can star collaborating back to the website.

[waldyrious]

Do you mean auto-updating company directory on website based on the awesome-open-company list?

Kind of. I was thinking the easiest approach would be to merge the contents of the site and the awesome-type list in a single repo, in simple markdown, and serve it directly using github pages from the master branch, so that people would only need to submit PRs and have them merged for the website to update. So we'd have a single repo, no explicit build step (github pages would handle that) and the content updating would be fully distributed/collaborative rather than requiring coordination with the companies, nor any web development work. @galuszkak what do you think about that simplified flow?

As for the social media, I think we can use whatever the person(s) who wish to maintain them prefer. For example, someone who's very active on twitter could handle that part rather than attempt to manage all accounts. Or if they'd prefer using Buffer and managing several accounts at once, that would work too. The issue here seems to be mostly manpower, not tools.

[nobodxbodon]

easiest approach would be to merge the contents of the site and the awesome-type list in a single repo

I agree. Main reason I asked about feasibility to outsource to the other open companies is, this task together with the items under "website simplifications" in #168 may seem not much, but the decision making and design process could easily span weeks if not months. Also there may be extra features we want to cover during the way, like improving for mobile devices, SEO, etc.

By introducing proper external (while still within the open company community hopefully) resources, everyone will be more engaging, and with the extra expertise in website development, the whole task is more likely to be accomplished in a timely manner. It seems worthwhile to spend some of the budget on this critical part to simplify future mantainence.

As for the social media, I think we can use whatever the person(s) who wish to maintain them prefer. For example, someone who's very active on twitter could handle that part rather than attempt to manage all accounts.

It'll be great if someone we know can take this responsibility, but we may have to take it before someone volunteers. BTW is there some guideline about making announcements on social media accounts?

[galuszkak]

@waldyrious we are using github-pages, the only part why we are using Travis for building is that github-pages didn't support i18n features at time this site was started, so we have plugin jekyll-multiple-languages-plugin, that is doing that. It's fully working with github-pages framework. We can change that build to gh-pages is pushed to this repository branch gh-pages and disable and remove opencompany.github.io but for me it's just configuration cosmetics.
There is possibility that github-pages support i18n now (we probably would have to investigate) but it would require migration on our side probably.

We have a French version done by @kyzh and Polish version.

I started digging to reestablish builds today.

[waldyrious]

I see, thanks for the details. I'm not sure we can call that merely "configuration cosmetics", though, when the build requires some knowledge of Ruby and Jekyll configuration. I wouldn't be able to make the fix you did at #178, for example.

Has there been any advances in native i18n support with Github Pages since when this site was originally set up with multiple languages?

[FinnWoelm]

Pretty sure there is still no native i18n support for GitHub Pages: github/pages-gem#401 😭

[galuszkak]

@FinnWoelm I've enabled back CD. i18n is working here based on plugin jekyll-multiple-languages-plugin.

I don't think Github Pages has native i18n. But I've made it back working with our old CI/CD via Travis. It's working back (yay!). If there are any changes to website that you would like to do @nobodxbodon feel free to send PR.