Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into making this a public repo #6

Closed
elisabethirgens opened this issue Apr 7, 2017 · 7 comments
Closed

Look into making this a public repo #6

elisabethirgens opened this issue Apr 7, 2017 · 7 comments
Assignees

Comments

@elisabethirgens
Copy link
Contributor

Can Hedwig be developed in a public repo? Yes! We think that would be awesome. Some of us have discussed, and considered the pros and cons — and here’s what we think.

tl;dr This design system is an excellent project for working in the open. There are a couple of things we need to be aware of, but that we are.

Benefits ✨

Working in the open has some really cool benefits:

Community involvement

We depend on the community for code, knowledge, inspiration and tutorials. Giving back to this community by sharing our work should very much be in the spirit of our company.

Transparency is cool

There are no secrets in a design system, and everything is there in the browser on the sites using it. We can’t see a reason why it’s necessary to develop it behind closed doors.

Awesome for recruiting

We do a lot of fun work on the team, and it’s super positive to be able to show some of it off. Having a public repo is like a batsignal for developers: come join us we’re awesome.

Fun & useful for contributors

There a personal benefit for contributors who can show off their work, and even ask peers for help.

Higher standard

Knowing that anyone and everyone can see your work, will hold us to a higher standard. If it helps us write better code and more useful commit messages, this is excellent.

Risks and concerns ⚠️

There are a couple of things we need to be aware of:

Security

Developers pushing to a public repo need to be consious of this. Our mindset should be that the moment we push a commit, that code is public knowledge. It’s important to make sure that certain details are never part of the repo: passwords, server names, deploy scripts and so on.

  • We can write guidelines around this.
  • We can consider Git Hooks as a preventive measure.
  • We can have an onboarding for new contributors.

Privacy

Developers working on the design system could feel they are being imposed with a transparency they don’t want. The people involved right now are excited about a public repo, but it’s possible to imagine someone else later feeling different about this.

  • If someone joining the project wants anonymity, they could use whatever GitHub account they want. It doesn’t have to contain their real name, or be the same one they’ve used before.

Licensing

Code in a public repo needs a license. We need to make sure that there are no conflicts between the license we choose, and the licenses of other parts of code we use.

  • We need to level up on licensing. 💪

Credits

Hat tips are polite anyway, but especially important in a public repo.

  • We can maintain a credits.md to say thank you for any code, tools and ideas we use.

Worth the extra effort?

There is potentially “more work” being created than when developing behind closed doors. It holds us to a higher standard on everything from hacks, commit messages and discussions in issues.

  • We can change our mind. If it turns out the benefits do not outweigh the extra effort, we can revert to private.

Do any other companies do this?

Yes! \o/ Here are some examples:
https://github.com/audi/audi-ui
https://github.com/buzzfeed/solid
https://github.com/cloudflare/cf-ui
https://github.com/Financial-Times/ft-origami
https://github.com/twbs/bootstrap
https://github.com/salesforce-ux/design-system
https://github.com/18F/web-design-standards

Stuff we need to figure out

  • Which license should our code have?
  • Which licenses are there on other code that we use?
  • Are there any conflicts between these licenses?

Anything else? Comments very welcome!

@elisabethirgens elisabethirgens self-assigned this Apr 7, 2017
@kaaveland
Copy link

Note that it's possible to work around the "accidentally pushed something that shouldn't have been public" problem by having a private repo here and open-sourcing a mirror of that. Eg. have a pull-request workflow to the private repo. Then, when things are merged to it, just push that change to the public repo. There are probably lots of ways to get this extra security that we don't push bad data.

For licensing, I suggest we look into what some of those examples use. I know that the MIT license is popular, it's much simpler than many of the other options (it's basically "do whatever, but don't blame us").

https://opensource.org/ might be a decent resource to learn about software licenses (Haven't checked in any detail).

@elisabethirgens
Copy link
Contributor Author

@kaaveland Open source mirror sounds really cool. Do you think the cost of setting it up and maintaining it is worth it for a repo like this one? To me it sounds like security we might want to invest in for an application with a higher risk profile, than what is basically UI components and CSS.

@kaaveland
Copy link

It's extra work, for sure. I don't think it should be necessary, but it's worth it if it's necessary to make the people who works on this sleep better at night.

@andreaja
Copy link

Suggested licenses: BSD 2-clause for source code and CC-BY-ND for icons etc.

This is the same as the Salesforce repo and makes a lot sense: it's liberal with the source and conservative with our iconagraphy (which may include trademarked logos and other branding related material etc).

@fredjens
Copy link
Contributor

@andreaja Sounds like a good idea. I also think we should try to avoid hosting fonts, icons and assets in the repo. And instead load those from a CDN. That will both load them faster, make the repo smaller and probably avoid legal issues specially with fonts.

@kaaveland Maybe it will be enough to just protect the master branch? It will work the same way with PR's but you don't need to keep your fork up to date. Also we will probably add a CI, and will consider visual regression testing to prevent unexpected changes.

@kjarnet
Copy link
Contributor

kjarnet commented Apr 19, 2017

I think opensourcing some of our projects can make a lot of sense, and I think you've covered a lot of important pros and cons. The only addition I can think of is that if opening up the project also means that all PRs will be publicly available (don't know if there's a way to do private PRs in public repos), then maybe it can cause some reviewers to hold back in fear of saying something that makes them look stupid in front of "the whole world"... Then again, maybe this can be a good thing as well...?

@bnhovde
Copy link
Contributor

bnhovde commented Jun 12, 2017

Closing this as Hedwig has gone public. 🖖 🎉

@bnhovde bnhovde closed this as completed Jun 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants