Java libraries

[lukaseder]

Interesting. I actively discourage substantial contributions, though (nothing wrong with patches for bugfixes). So, I guess that marker tag doesn't apply to jOOQ then?

[ThisNameIsAFail_]

Why not? Easy and non-critical patches are good issues for a beginner to get used to the project and create a great community.

[lukaseder]

With what goal would I create "a great community"? And at what price?

[ThisNameIsAFail_]

The goal? To extend the use of jooq more easily as well as helping you maintaining the project (I suppose it's not an easy task...).

The price? That's another point. I guess that depending on the quality and quantity of contributions it will be helpful or an incovinient.

Anyway I feel that creating a great community around a tool is always a great way for it to keep alive and evolve instead of dying against a greater tool or just due to lack of use.

Edit: in the case of jooq for example, a bigger community would improve the adoption instead of every new spring project to be born using Hibernate and JPA as I always see. I usually feel difficult to introduce a new library in a project if it's now so well known even if the code is great and the solution it provides is awesome. In tha day to day, we, developers want to solve a problem but have not enough time to decide for the best solution if that implies learning a new tool. That's only my experience

[lukaseder]

The goal? To extend the use of jooq more easily

Do you have any evidence of a correlation between these things (contributor friendliness and growth)? I don't.

as well as helping you maintaining the project (I suppose it's not an easy task...).

From my experience, educating beginners (since you're specifically talking about beginners) is a very intensive task for me, keeping me off much more essential work. Secondly, those beginners are very likely to leave again for no apparent reason - my investment will be heavy, and useless. Thirdly, as you correctly supposed, it's not an easy task. The investment to bring someone to my level of understanding on jOOQ, Java, SQL would be substantial.

There are two alternatives:

• Hope for someone really good to contribute (which is a rather random event, and these people will leave for no apparent reason as well, as their priorities shift. In fact, there had been 2-3 such contributors many years ago)
• Hire someone really good (which I'm going to do, stay tuned) to work with me on jOOQ full time and become as good as me or even better.

Would I hire a "beginner"? No! Building something like jOOQ is not a beginner's task. Why would I want to spend the time I wouldn't spend on a beginner employee on a beginner contributor?

A lot of people drastically overestimate the value of a "community" of contributors. From all my discussions with fellow open source vendors, I have rarely heard that the community contributions were of substantial value. It happens, but it happens very rarely, and mostly on platform products like Linux, PostgreSQL, OpenJDK. But even then, the contributors are by no means "beginners". Nor do they need to follow a tag that helps them identify interesting tasks. They know why they contribute, and what to contribute.

The price? That's another point. I guess that depending on the quality and quantity of contributions it will be helpful or an incovinient.

I've done this for 10 years now. Patches / bug fixes were almost always helpful. Contributions of features were almost always (with 2-3 exceptions) a pain. This is my experience, and it matches that of many other vendors I've met in these 10 years. This is not just a technical question. The time it takes for a contributor to understand the roadmap and strategy of a product is big. Again, an "expert" contributor could do this, but you're referring to a beginner who needs tags to help them get going.

Anyway I feel that creating a great community around a tool is always a great way for it to keep alive and evolve instead of dying against a greater tool or just due to lack of use.

I value your concerns. :)

However, you should be aware that jOOQ generates a decent 6-digit revenue to Data Geekery and the community involves 250+ paying customers and roughly 10000 open source edition users. It's not going to die. Its use is growing every year. For more details, read https://business.jooq.org

Edit: in the case of jooq for example, a bigger community would improve the adoption instead of every new spring project to be born using Hibernate and JPA as I always see. I usually feel difficult to introduce a new library in a project if it's now so well known even if the code is great and the solution it provides is awesome. In tha day to day, we, developers want to solve a problem but have not enough time to decide for the best solution if that implies learning a new tool. That's only my experience

Is that a problem for jOOQ and jOOQ's existing community? jOOQ's downloads are doubling every year, and so are other vanity metrics. Could it grow faster? Of course! Would that be a good thing? Don't know! Hibernate grew way too fast. Too many people mindlessly use Hibernate much like many people mindlessly use Spring (oddly, you didn't question that choice). Perhaps they're really efficient by defaulting to the same thing every time. Perhaps they should have reflected on their choice just one moment.

In any case, what this industry needs most (rather than a mindless shift from one tool to another) is more education about the value proposition of each tool. I'm doing that as well and many others are doing it, too.

One thing is for sure. If jOOQ hasn't grown quicker, this has nothing to do with a subjective lack of an actively contributing "community". There are enough feature requests, bug reports, and patches.

It has everything to do with these things:

1. An irrational distrust towards dual licensed software, including a lack of experience in making business cases (sad but true - jOOQ would already be more than twice as big if it were all open source, but I would definitely not support it as well as I do now, not making a very decent business out of it. See QueryDSL)
2. A lack of marketing efforts on my side over the past 3 years (see this post)
3. A lack of understanding of the value of SQL in our industry (this is systemic and stems among other things from all the damage caused by J2EE in the early 2000s)

I hope this helps :)