Unify Ecosystem

[brodock]

I would like to suggest that you unify all grape related projects into a single "organization", to make the ecosystem around it stronger.

As an example of what should be considered (I've listed the most active and still maintained projects):

Functionality

• grape
• grape-entity
• grape-rabl
• grape-cache_control
• grape_ape_rails
• grape-rails-cache
• grape-cors
• grape-active_model_serializers
• grape-activerecord
• grape_logging
• grape-doorkeeper

  Documentation

• grape-swagger
• grape-swagger-ui
• grape-swagger-rails
• grape-slate

  Monitoring / Instrumentation

• newrelic-grape
• grape-librato
• grape-appsignal

  Test Helpers

• grape-entity-matchers

[kuraga]

And consider grape demodulation (separation by several gems).

P.S. @brodock insert links to project pages, please?

[brodock]

@kuraga sure! I will edit the post

[kuraga]

Thanks very much about this topic!

[dblock]

Generally I don't find discoverability being a problem, but I understand how the ecosystem could be stronger.

I feel torn about the unification of such things, I really like the distributed nature of open-source and I also really like that owners of gems stand behind those gems as opposed to having some centralized Soviet style "organization". I wish there was a virtual "organization" that could collect projects like this other than through a github wiki or page.

Would love to hear everyone's thoughts and suggestions!

[brodock]

I was more concerned of some gems being maintained as fork of a fork of a fork...

My initial suggestion is to delegate the ownership of the repositories for their respective maintainer, while having a "single point of discovery" here, and perhaps this could potentially help related gems talk to each other and collaborate in a better way.

Things like enabling gitter.im for the organization and for every project can also help with that

[sunnyrjuneja]

Hey @brodock, thanks so much for suggesting this. It's something I thought about frequently myself. The burden of maintenance is a tough question and OSS requires a group effort. I don't think discoverability is a core issue because the wiki includes a list of projects. A better suggestion to improve discoverability could be to include the link to related projects into the README. This would let people realize that grape has a thriving ecosystem and that are tools they can leverage.

However, I'm very frustrated with the state of grape-swagger-rails. If you google grape swagger rails, the first result is a fork of an earlier project:

https://github.com/BrandyMint/grape-swagger-rails

On first glance, the project looks maintained but if you look at the issues (https://github.com/BrandyMint/grape-swagger-rails/issues/50), you'll see that this an old project and that there is yet another fork! It would be great if there could be a single repo instead of three with this project. An org would solve this issue since there would be many owners.

I like your current suggestion of unifying grape tools in one particular org BUT I think your list is too long. I would prefer an org with core projects (grape, grape-swagger, grape-entity, etc) and another repo for "great to use with." For example, I'm not sure if grape-doorkeeper (I prefer wine_bouncer) should be in the umbrella org.

[brodock]

@whatasunnyday sure! I listed all the gems I could find that are somehow maintained and may look useful for the majority of users.

I understand that selecting the "most useful ones" (you can call it core), is a good start point... and be open to include others as soon as they become more mature and wild used.

What do you think?

[sunnyrjuneja]

I think that's a good call.

[hobofan]

+1 to what @whatasunnyday said.

I generally like the idea of an umbrella org, because it usually comes with some quality guarantees (which of course mean more burden on maintainers).

I think especially semi-popular gems could benefit from it (or some other form of enhanced communication), since quite a few of them ignore facilities provided by grape (e.g. ignoring Helper modules and implementing a half-baked solution themselves).

[towanda]

+1 to what @whatasunnyday said.

I like the idea of having a "single point of discovery", with the core gems, and not to worry about using the wrong fork.

[dmitry]

Really nice idea. I believe it would be good to include the most popular/used related projects to the org. It would also be good, if everyone who is interested in the "grape plugins" can collaborate more tightly to improve functionality of the projects.

[hedgesky]

I agree with @hobofan. I think list of extensions in Readme would be very convenient for newcomers.

[dblock]

I take PRs for the README that link externally. For example we have links to grape-entity and others that are commonly used and frequently needed.

[dblock]

Well, it's happening! We're moving to https://github.com/ruby-grape shortly.

[brodock]

thank you very much :)

[dmitry]

Great news!

[dblock]

Happy to close this now! Please open specific work-items around community organization in https://github.com/ruby-grape/ruby-grape.github.io/issues. Also hitting Send on an announcement to the Google group.

[dblock]

Can someone please port the list of projects from here to https://github.com/ruby-grape/ruby-grape.github.io? See https://github.com/ruby-grape/ruby-grape.github.io/issues/3.

[dblock]

^^ done