bendrucker
commented
9 years ago 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 https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328) 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:
- I started using browserify-shim
- I watched the repo via Github. I responded to some issues.
- I responded to a tweet from Thorsten, the creator, asking for help w/ issues and PRs
- I asked to be added to exposify, a dependency of browserify-shim to help merge a few PRs (https://github.com/thlorenz/exposify/pull/8, https://github.com/thlorenz/exposify/pull/4)
- I turned a regular expression in exposify into a module called has-require via https://github.com/thlorenz/exposify/pull/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.
- 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!
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 :)