Blog post: A new approach to managing jMonkeyEngine

tl;dr: I’m gonna be making dedicated topics to the following topics soon:

Making friends with companies

jMonkeyEngine might not become my livelihood in the foreseeable future, but for many others it can be. For some it already is. I need to come up with more incentives for companies to get in touch with us.

Paying for things

This is risky business, but I’ve had some experience with it now, and I think I can make it work. jME has received generous donations in days past that we don’t even know what to do with, so we just sat on it. This isn’t good. All this time we essentially had a budget for taking small risks, but we hardly took any of them! That’s gonna change now.

Now that I’m working full time I’ll also be spending my own money on some jME micro-projects.

Streamlined path-to-first-contribution

When someone wants to contribute to jME the path to making that first contribution is not crystal clear. We do an OK job of onboarding contributors, but we can do a whole lot better.

p.s. thanks to @rickard for asking some questions and sharing some thoughts that helped me collect my thoughts.


I’m not sure I agree with this. I think the path is pretty clear to those qualified to take it.

A proper contribution to an open source project is hard. It needs to satisfy a bunch of constraints that a personal project doesn’t. I don’t think we’ve made it any harder than it needs to be.

Core changes deserve a LOT of scrutiny. In fact, sometimes we let things in that never should have made it already. I just reverted one recently… but the scrutiny is what leads to a quality core.

Everything else should be a plugin. That process could be streamlined a lot. Even I don’t do it. Plugins have a vastly different life cycle than the engine (which is only released every 3 years or so it seems… and making ‘core’ larger isn’t going to make that better). We need to improve the ability to add and maintain plugins. We need to then improve the visibility of plugins. We need to prioritize engine changes that facilitate extension through plugins.

It’s even the best/easiest way to incubate things that really should be part of core someday.

You might find that you can’t afford to pay for what you get for free. There is an interesting phenomenon that happens when the dynamic changes from philanthropist to contractor. I don’t know exactly what you’re thinking so it’s hard to say.

Though, given how often I have to do things two and three times on the forum before it accepts my request… perhaps paying someone to fix the forum wouldn’t be a bad idea. :wink:

1 Like

As far as I can see, today only contribute to jME3 those who needs a new feature or have a use case to. If you are using jME3 as it is, you can’t contribute with nothing new.

This is my case, at moment, everything I need, jME3 have already, be it using the core or using Lemur. I know this is hard to manager, because if I have no use case, how may I develop and test? And which PR should be merged on Core and which one should be added as plugin?

In my opinion, to make the contributions more crystal clear, will need someone to manage new requests/bug fixes and distribute over community to do it. And instead of spending time distributing task, wouldn’t be better just develop? Dunno.

That’s what I think.

I’m not just talking about core contributions though. There’s a lot of cool stuff you can do without delving deep into core, like @methusalah’s RTS library. I direct capable contributors to projects like that.

[quote=“pspeed, post:2, topic:34550”]
You might find that you can’t afford to pay for what you get for free.
[/quote]I’m well aware. But I wanna do some experiments. More on that soon.

Fair enough. I’ll hold my opinions then… there’s a chance you’ve thought of something new.

Things to be extremely wary of:
-associating hours to $$
-winner-takes-all bounties


Using an open core or professional service model seems to make sense for a developer tool like jME, see e.g. what Goo Engine is doing (and what Ardor3D tried to do), RoboVM is also in the same boat.

Crowdfunding is another option (people love funding open source projects), but its not really a steady source of revenue, so a lot of companies kill the OSS portion after the crowdfunding is past so that they can keep making money.

The challenge with all of those options is keeping the project “clean” open source. Once you start adding proprietary parts, you don’t really have an incentive to keep maintaining the OSS portion and it just gets “sucked” into the proprietary part. Too many projects ended up there (too many to list in this thread even).

1 Like

My two cents :

I’m a pure user of JME, I’ve never contributed to the engine with pull request, plugin or anything else in the code. And this is mainly because I don’t know how to.

I would love to push my work to the community, and try to adapt it to everybody needs if it’s possible, but I have no experience with that kind of thing and I don’t know where to strat. I simply continue to code my own projects, in the scope of my own needs, which is not usefull for the community.

I admit that I don’t want to spontaneously spend time in the JME doc to learn how to. My bad ! This is because, like many, I code in my rare free time and I want to go forward fast. But I would love that someone come to me and tell me “let’s make your project a JME contribution : let me show you.”