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

Open Source #14

Closed
designMoreWeb opened this issue Jul 1, 2015 · 1 comment
Closed

Open Source #14

designMoreWeb opened this issue Jul 1, 2015 · 1 comment

Comments

@designMoreWeb
Copy link

Hey Ben,

I was unable to ask you this question at the AngularJS talk at Google, but i really want to improve my web dev skills and try to get involved in open source projects I believe thats the best way i will be able to improve and i just need help in understanding everything and some guidance. Please help me out and let me know thanks :)

@bendrucker
Copy link
Owner

I believe thats the best way i will be able to improve

Agreed!

To me the best way to do open source is to focus on all parts of the story. A lot of people see the beginning (starting is hard) and the end (a sliver of internet fame, pay raises, new friends) but miss the meat in the middle.

I'm a strong believer in modularity (see sindresorhus/ama#10 (comment)) to a point that other people might view as obsessive/unnecessary. I disagree.

Good software is composed of lots of small parts. Here's a story of one:

  1. I started using browserify-shim
  2. I watched the repo via Github. I responded to some issues.
  3. I responded to a tweet from Thorsten, the creator, asking for help w/ issues and PRs
  4. I asked to be added to exposify, a dependency of browserify-shim to help merge a few PRs (add ability to pass args thru browserify transform. closes #5 thlorenz/exposify#8, feat(transform): allow pass options via browserify transform thlorenz/exposify#4)
  5. I turned a regular expression in exposify into a module called has-require via Extract require check to has-require thlorenz/exposify#10. has-require was originally a pure copy of exposify's code but has since become more efficient and eliminated bugs in the original implementation.
  6. I pulled almost the entire exposify library into a more generic modules, replace-requires and globo.

The meat of exposify used to be a fairly dense 64 lines of source code (https://github.com/thlorenz/exposify/blob/v0.1.4/expose.js)

Now it's a readable 10 lines. Some of those same libs I wrote along the way are in use in:

https://github.com/thlorenz/proxyquireify
https://github.com/bendrucker/proxyquire-universal

The middle of the story is where the major of the learning happens. The beginning is about being willing and eager to help and taking your ego out of the picture.

A maintainer might accidentally make a dismissive comment because they have a lot on their plate. Don't take it personally. Be polite, persistent, and helpful in whatever way you can.

Focus on a problem domain where you think you can find opportunities to spin out new packages.

I did this with https://github.com/bendrucker/test-peer-range

It helped me learn a lot about semantic versioning. If you dig through the dependency graph you'll notice that I had to write nearly a dozen packages to keep the core library as focused as it is.

If you don't have any ideas, start contributing to a stable project with a few hundred stars. Contributing to things like Angular and React is generally a poor use of your time since the political and logistical barriers to contribution are high.

Feel free to continue to ask questions as you go!

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

2 participants