Currently I’m using c3 for a work project and it reminds me of how the open source world works. When something great and pretty gets created, people want to use it. When issues arise, some are easily fixable, others start involving api changes, others are downright difficult to track down. However, when all is said and done, some issues will take too much time to kink out. However, as dependents increase the demand for a “perfect” library also increases. We start seeing wholes from some many different places

• When using with a huge input
• When attempting to optimize with a huge input
• When using with high number of inputs
• When attempting to optimize with high number of inputs
• When a feature was a second thought
• When mix and matching features
• When it doesn’t interact cleanly with obvious use cases

There are likely more cases. Now, theres something to be said for “why isn’t anyone helping?” And that’s really what this blog post is about.

I feel so alone

So, put your feet in the shoes of a developer of a successful open source project. Imagine that you didn’t get a job from it but it is used everywhere. Imagine that you want to keep it free. Imagine that almost everyone who comes there posts an issue but almost never helps to solve them. This can get tough. It hurts and I believe it eventually leads to abandonment or resentful yet honest comments to innocent people. How do we avoid this? Thats easier said than done

• Make sure the code is clean – Something like lodash is a great example because each aspect is in a small little function. However, lodash is also an exception to the rule as it does very little. lodash doesn’t visualize anything, lodash doesn’t transform much that hasn’t already existed. As a result, we should only respect how nice it is to have a very simple goal
• Make sure the code can be conceptualized – This is something I think we are missing more. A flow chart that point people to the correct files.
• Make sure your code is as dry as possible – If theres an error in a dry aspect. Then all you have to do is modify that dry code. The more seperate parts that do the same thing, the harder it is to track down when things go haywire
• Make sure you aren’t doing too much, and if you are organize. – This is in my opinion the most important. Something more difficult is when you are overloading constructors or having a parser/ajax and something else. You can allow your users to do the ajax. To follow directions. In this manner you have to worry less about retreiving from a url and care more at making what you are doing is done well.
• Tests are Examples – Instead of seeing “examples” generally I like to go to the test folder to see how things work. The reason for this is usually I’m looking for a fringe peice of API that isn’t well documented.

Be Honest

The open source world is hard. But to keep it alive, we don’t need our successful to die out in a fire, we need them to tell the world “hey! I’m over it!”. We need to have people realize that each individual is what it takes to make a project successful. If someone posts an issue, I would believe its ideal to lead them in the direction to fix it themselves. That merge the request. Its simple but makes your life easier and supports the opensource culture as truly “by us for us”.

Yell At Companies

I’m under time constraints (I probably shouldn’t be writing this but rather work 13 hour days 7 days a week… jk ;). However, companies often use aspects and then avoid helping out later. Companies pay programmers and programmers should give back on company time. Otherwise we go down a slippery slope over tons of people use and the creators get no pay nor help.

That being said, I’ve never had an open source project that has become a booming success. Nor have I followed all these rules. So I suppose you can ignore everything I said. Its a thought