Stepping down from Urho lead dev role


#22

I would vote against a vote. This is something the active devs should decide, not the community.
IMO, in the best case, in a few weeks and after some internal discussions, the most active devs made a decision and we get a “Urho’s new dev lead is X” news post :slight_smile:


#23

Naturally, I can’t speak authoritatively at this point, but my belief is that the remaining core devs should decide among themselves how leadership is to be organized.


#24

And I already gave my personal reason to Lasse why I won’t be taking that position. So, I will pass.


#25

Sorry, I meant that more as a joke. My real point was that there should be a lead, even if it’s just by title.


#26

It feels like I only just got into the fun and already the project author is jumping ship. I didn’t know my code was that bad :stuck_out_tongue:

I’m sad to hear you go, and I wish you all the best. Urho3D is something special and you should be proud.

On a more organizational note, if this project is to continue optimally, there needs to be a lead dev who has the final decision on changes. Typically when people step down from other projects they appoint the person they trust most to take their place, but since that hasn’t happened here, we might have a problem.

I don’t actually know who the “core devs” are, is there a list somewhere or is it just defined as “those people who commit code fairly regularly”?

Either way, if I am somehow on that list, I don’t believe I know enough of the engine to make competent decisions. I know the ins and outs of my IK contribution but that’s about it.


#27

It looks like you have time and energy to get to know the project, also you can ask people, also @cadaver won’t go away from answering your questions, so I don’t see why you can’t take over leadership, so don’t run away too quickly. I hope you and @Eugene might decide as @weitjong does have reasons not to.


#28

That’s really sad. My only fear is that the engine itself will turn into a giant cumbersome mess with bad design choices.I saw it happening once so i hope it won’t be the case.Who ever going to be the leader , keep your eye on current easy , practical , indie friendly design and keep following it what ever takes.


#29

Everything flows. Thank you Lasse for creating and maintaining such awesome game engine, you are the man.

Actually, I don’t think Urho3D really needs one lead dev. I always thought of totalitarianism as the more effective form of government than authoritarianism, I mean, there are already core developers in project, why don’t just let them vote for big changes? AFAIK, some OSS projects are developed this way, e.g. Debian


#30

The reason for final authority is to avoid disagreements which lead to people going with their own fork, thus fragmenting the community and progress.

My opinion about who should be the lead is whoever is most familiar with Urho3D’s design and code, and has the most experience working with it (and has to be competent enough of course).

That’s quite a huge demand since Urho3D has many domains and its own code and third party libraries for the lead to be familiar with.

When thinking about it a way to deal with this big scope problem is to distribute responsibility for core developers over different domains. One is responsible to the physics, one for rendering and sound, one for networking and AngelScript, and so on. Each one is responsible to be familiar with Urho’s and 3rd party’s design & code of his domains.
It will also help with processing PRs since you’ll have many people being qualified to handle reviewing PRs for their specific domains.
There’s still place for a lead to oversee the whole thing(officially assigning domain devs, final word, etc).

This is the best approach I can think of.
If we agree about it the next step is to specify development domains, and after we have a new lead, assign volunteers.


#31

Generally I remember it has been hard to find people who want to commit to a steady dev role, even if their contributions have been good. Ie. some are happier just contributing occasionally, or cannot promise a commitment.

For the reverse case, I’d certainly hope no-one who wants to contribute and take an active role, and has a good contribution history, is turned down now.

EDIT: forgot to say what @Eugene touches below: contributions often determine authority in most natural way. E.g. @weitjong for the build system, or dark_sylinc in Ogre when he began the whole 2.0 renderer revamp.


#32

I suggest to move on and return to the topic about leadership if it become important. BTW, splitting Urho into core and modules shall decentralize responsibilities.


#33

I agree with you:
By having a lead for each engine “section”(physics, rendering, …) is the most realistic and manageable way to continue.
It would also make the eventuality of a replacement of a team member less disruptive.

Another pro is the team structure would also integrate well with the community-made components and subsystems as the actual roles and competencies would be well defined.

Then the actual project lead(aka guy with the last word) could be chosen by the engine sections leads basing on trust and competencies.


#34

Although assigning team members over specific modules makes some sense, in practice we haven’t currently got the active contributors to split it up that fine-grained. Also, I feel artificially assigning titles to inactive contributors based on promise could lead to problems.

At the moment, I feel that @weitjong and @Eugene are both active and talented enough to at least be the guiding voice in the interim, until hopefully another talented contributor appears. With the community repo brewing, I think we will be opening the door to lower quality or less relevant contributions, that can also serve as a side channel for PRs that don’t make the cut.

In the meanwhile, we can explore options to ensure the long term project health. Eg,

  • We can look at bringing Urho and Atomic closer together, or maybe pulling components from atomic into the community repo.
  • We could re-evaluate the core of Urho and look at bringing in more third-party libraries to essentially out-source the problem (eg, rendering, UI)

#35

Not sure what’s the scope of “steady dev role”, but perhaps more people will be ok with taking a role with smaller responsibility over a single domain.

Also the role doesn’t have to require active development (tho obviously it’s desirable), just being familiar with the domain so RP reviews can be done is good enough for a start.


#36

Yeah, with “steady dev role” I meant that one is following their area of the project (eg. issues and PRs), not necessarily doing active development the whole time, but the sense that one hasn’t just dumped in code once and then moved on.


#37

Atomic and Urho can mutually benefit from each other without being merged into a single project… our communities could certainly be more in contact though. I guess from a user adoption perspective, a merge or some kind of official endorsement would be beneficial, but that’s way beyond my department. While I don’t necessarily agree with something like that, it’s a fact that your forum is way more active and helpful, while we are quite active on Gitter for realtime support. Larger and more active communities also tend to attract more users, it’s a kind of snowball effect, once you have enough momentum the thing goes on on its own. Again, I’m just stating the facts here, personally I think Atomic and Urho have different enough scope to the point that anything beyond a friendly approximation on both sides wouldn’t be justifiable.

That’s one of the most discussed topics in the Atomic community. We’ve been discussing for example swapping the renderer for bgfx for a long time, and one of our contributors even started making something in that regard. One has to be careful though because it could be a shot in the foot: you may end up with just a bunch of libs frankensteined together since these days you find high-quality permissively licensed libs for absolutely everything, from ECS to autobinders.
However, by sensibly ‘outsourcing’ a few more things, perhaps the internal efforts could be focused on modernizing the core, what’s another recurrent discussion in the Atomic community.


On a related note, why that guy who maintains the Russian tutorials/docs and community wasn’t mentioned here? I don’t know how active he is in terms of core development, but he seems to know a lot about the internals, and also made some quite amazing code to extent the functionality in the right direction imho (e.g.: sprite batcher).

It seems nobody is looking forward to be the next cadaver :laughing:


#38

Sorry to hear that. It’s not that much I’m tampering with Urho, but afaik this engine has been around about ten years or so to days… that’s a lot of time, so I can see your decision.
Anyway you did a very good job. Not easy to see around such polished things, and I’ve been seeing code a lot…
Best wishes for your next enterprise, hope it’s so lucky as well.


#39

I quite agree with @Enhex to distribute responsibility for core developers over different domains of Urho. But I still feel there will be need for an Arbiter when there are more than one conflicting ideas


#40

I think the better term is project lead, the one that oversees, makes contributions and the final decisions. I agree, the current roles seems to be more natural than by assignment, Wei-Tjong (Build), DragonCastJosh (Renderer), Eugene/HD_ (Core), and so on…

I got interested one time when Lasse mentioned first this topic, but the way things are moving right now and with other interesting ventures, I’m leaning towards a sharper fork eventually.

Lasse should definitely appoint the next lead if the developer/contributor is willing and accepts it.


#41

I feel sad. IMO, Urho3D is the best open source game engine all over the internet! I read most of the code. They are clean, elegant, well-designed, implementation knows where to stop. Even the 3rd party libraries are well selected! I’ll contribute as much as I can.

IMO, it is the open source version of Unity. With the character of open source, from many aspects, it’s even better. Now the growing baby’s father is leaving. Please keep growing… Urho vs other commercial engines is just like Blender vs commercial modeling software. Now Urho’s Ton Roosendaal is leaving. Sad.

Cross fingers and go team!