-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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). |
@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. |
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. |
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). |
@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. |
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...? |
Closing this as Hedwig has gone public. 🖖 🎉 |
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.
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.
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.
Credits
Hat tips are polite anyway, but especially important in a public repo.
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.
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
Anything else? Comments very welcome!
The text was updated successfully, but these errors were encountered: