I am also a bit new creating open source libraries, but I have tried to understand what makes a good (and perhaps "famous") library by studying some cases. This is what I came up with:
Focused on a task: Your library is GOOD for something. A problem, a scenario, a desire.
It's just a library: When using your library the developers should not feel they have a new constraint, something that changing in the future is going to be costly. That's pretty much the difference between a library and a "framework" for me.
It provides added value to you or your team: Does it make code more readable? Does it enable your development team to go faster? Can you do something with it that otherwise would be impossible or too difficult?
It's simple to understand: Most libraries try to add an abstraction layer so they are easy to use, and hide some or all of their magic. We can all guess that dependency injection libraries do on the back, but there are complex scenarios like multi-threading, web platforms and such that they are making transparent. Is your library allowing the developer to focus on his problem domain instead of focusing on the platform, language or whatever?
And then it also comes down to your support of course.
Good and full documentation! Many times in my company I am in charge of selecting libraries for XYZ problems, and I am always analyzing how complete their documentation is. I have seen some great libraries out there with NO documentation at all, or perhaps just a blog post! I am afraid we have to skip those ones even if they work great.
Do you have a repo like Github where you can receive Issues, people can collaborate, and you can keep up with the new community you are building? Are you replying to those issues? Have you welcomed others to your project?
And those are at least some of the key points for me that make a great library. Of course, ease of distribution, ease of installation, performance, unit testing, integration testing, and many other things also are necessary.
I am in no scenario an expert creating open source libraries, I have started very recently to create some! But thankfully to the great opportunity I have at work, I have been able to understand what it takes to "choose" one, so thought this info could help you.
Make sure to write a dev.to post when it's ready! And don't worry about a 100% polished finished product, otherwise you'll never go live.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey there!
I am also a bit new creating open source libraries, but I have tried to understand what makes a good (and perhaps "famous") library by studying some cases. This is what I came up with:
Focused on a task: Your library is GOOD for something. A problem, a scenario, a desire.
It's just a library: When using your library the developers should not feel they have a new constraint, something that changing in the future is going to be costly. That's pretty much the difference between a library and a "framework" for me.
It provides added value to you or your team: Does it make code more readable? Does it enable your development team to go faster? Can you do something with it that otherwise would be impossible or too difficult?
It's simple to understand: Most libraries try to add an abstraction layer so they are easy to use, and hide some or all of their magic. We can all guess that dependency injection libraries do on the back, but there are complex scenarios like multi-threading, web platforms and such that they are making transparent. Is your library allowing the developer to focus on his problem domain instead of focusing on the platform, language or whatever?
And then it also comes down to your support of course.
Good and full documentation! Many times in my company I am in charge of selecting libraries for XYZ problems, and I am always analyzing how complete their documentation is. I have seen some great libraries out there with NO documentation at all, or perhaps just a blog post! I am afraid we have to skip those ones even if they work great.
Do you have a repo like Github where you can receive Issues, people can collaborate, and you can keep up with the new community you are building? Are you replying to those issues? Have you welcomed others to your project?
And those are at least some of the key points for me that make a great library. Of course, ease of distribution, ease of installation, performance, unit testing, integration testing, and many other things also are necessary.
I am in no scenario an expert creating open source libraries, I have started very recently to create some! But thankfully to the great opportunity I have at work, I have been able to understand what it takes to "choose" one, so thought this info could help you.
Make sure to write a dev.to post when it's ready! And don't worry about a 100% polished finished product, otherwise you'll never go live.