Mega-discussion of next steps

[saiichihashimoto]

Inspired by opensourcedesign/logos#5 and @jdorfman, here's an initial wishlist:

• Allow for logo contributions (more easily than now, anyways)
• Use other repos
• Allow for metadata (like license, copyright holder, etc.)
• Access the list of logos via JS (similar to how it currently is)
• Access the logos without having to npm install
• Have the pngs in here as well rather than generated on ILS?

As discussed in opensourcedesign/logos#5, we're not looking to add a whole lot of complexity to InstantLogoSearch (which uses this repo), but this repo can export an object that DOES have all of the metadata considered without ILS doing much about it.

It might make sense to use git submodules for including other's logos. We could fork their repos to rename logos how we want and it would allow for this repo to be directly be used for its files, rather than NEEDING in to be an npm module. With the forked submodules, we might also be able to remove these js files specific to each dependency.

Converting all the SVGs to PNGs ahead of time isn't exactly a fun process. For ILS, we're using MaxCDN to cache these so we don't have to do it all the time. In the end, maybe we don't check in PNGs and call that a day.

opensourcedesign/logos is about open source logos. We're just logo in general. If we export metadata that exposes our open source logos in this repo, then we can just reuse each other's work and that would be fantastic.

[jdorfman]

@saiichihashimoto sorry for the delay I was getting over a cold.

Looking through package.json I didn't notice any svg-to-png converters so are you just using imagemagick?

Either way, I think just exporting both .svg and .png incrementally on deploy would be a lot less expensive than doing it per request (when not cached on the CDN).

SVG's are awesome but it doesn't always fit everyone's use case. Not checking them in could create a bad UX IMO.

...then we can just reuse each other's work and that would be fantastic.

Couldn't agree more. What are the next steps from here?

[saiichihashimoto]

Currently, https://github.com/kogg/InstantLogoSearch is doing the conversion. When necessary. The CDN caching for us and we haven't had any real problems. We weren't really considering people using the github repo directly, so that seemed good enough.

Basically we want https://github.com/opensourcedesign/logos to house our website, this repo to house the logos, and somehow account for all the use cases.

What was the plan with https://github.com/opensourcedesign/logos? How were you thinking of structuring that repository? It seems more or less empty ATM

[jdorfman]

Basically we want https://github.com/opensourcedesign/logos to house our website, this repo to house the logos, and somehow account for all the use cases.

I like your thinking.

What was the plan with https://github.com/opensourcedesign/logos? How were you thinking of structuring that repository? It seems more or less empty ATM

Let me talk to my peeps (cc: @bnvk)

[saiichihashimoto]

Sorry, I meant to say that https://github.com/kogg/InstantLogoSearch should house our website. :-) It's already housing instantlogosearch.com and we like that. However, if this repo houses the logos, then yall can use it for https://github.com/opensourcedesign/logos, as well.