You mayhaveheard that Node.js has been forked to create io.js. Personally, I think this is a good thing for a number of reasons.
io.js intend to take V8 releases as quickly as possible. This is great because io.js will be able to take on any new features available in Chrome and will also avoid any lingering bugs.
No corporate dictation
A lot of different companies and individuals use Node.js. Unfortunately, until recently, only one of these really has had a say in what happens with it - Joyent, the corporate sponsor.
io.js intend to work under an open governance model with the aim to be as transparent and to work off of a consensus. This works in everyone's favour as the technical committee will be working to push the technology as a whole forward, rather than things that may benefit the corporate interests.
Already io.js is seeing an uptick in community participation. At the time of writing, the logo ideas thread has over 430 comments and has only been open for 3 days. Couple that with the active development going on in the v0.12 branch and you can see that the community is enthusiastic about io.js.
In his post on Medium, Mikeal addresses some concerns about fragmentation, including fragmentation of effort. In his last paragraph about fragmentation of effort, he says:
I don't see this as a zero sum game, we aren't dividing the entirety of potential effort between two projects, we're increasing the overall effort being put it.
Back in 2004, when I was in secondary school, my P.E. teacher said something during a basketball lesson:
Practice doesn't make perfect, practice makes permanent
We all looked puzzled when he said it, then he explained:
If you practice doing something wrong, it gets ingrained into you and it's difficult to change that.
It's very true, and the quote has stuck with me ever since. It can be applied to almost everything you do in life, from programming to cooking to sports. This is why it's important to do two things:
Ask for help
Ask for feedback
Asking for help
Nobody, no matter what their position, experience or background, should be afraid to ask for help. Asking for help means that you understand your limitations and that others may be better at something than you, even if it's just one small thing. Everyone has their strengths and weaknesses.
Nobody should be afraid of giving help either. You gain nothing by keeping your experience and knowledge secret. Everyone had to learn from somewhere and almost everyone has learnt from others. Keeping your knowledge and experience to yourself simply means that you make it harder for others to join you in doing whatever you have the knowledge and experience of.
Adam Savage (one of the Mythbusters) talked about asking and sharing in his 10 Commandments for makers address at the Bay Area Maker Faire.
Asking for feedback
Everyone gains from you asking for feedback. It allows whoever is giving the feedback the opportunity to express their opinion and allows you to see what others think. This also opens a window for discussion, meaning that you can potentially find out things you didn't know before which in turn could help you improve.
Never simply discard someone's feedback without a conversation, talking about someone's feedback can help you see it from their perspective and could completely change how you look at it. If after a conversation you don't agree with them, then fine, but at least you took the opportunity to explore.
Over the past 2 weeks I've been rebuilding this site, having left it disused for nearly a year and a half. As I was building it, I decided to use a PHP templating engine that I wrote over 2 years ago. At the time I decided that I didn't need to document it as I'd remember how to use it and that it was straightforward enough.
I was wrong. I loaded it up and then had to look for one of the test projects I'd used it on to try and figure out how to use it. Even then, I still couldn't get it. I eventually managed it by looking through the code and by trial and error, but it shouldn't have been that way. I should have written documentation.
When writing a library or code snippet, examples and documentation are hugely important. If you're releasing it on a site like GitHub, then people are extremely unlikely to use it if there's no documentation or examples. If they can't figure out how to use it, most of the time they'll move on. Even if it's for your own use, at least write some useful examples. You'll thank yourself in the future.