Are we duplicating effort on Krumo projects?

[scottchiefbaker]

I just found this repo via Google. I've been maintaining Krumo here:

https://github.com/mmucklo/krumo/releases

For quite some time now. We should team up and combine our efforts.

[kktsvetkov]

@scottchiefbaker There is a lot of work done on the mmucklo/krumo fork already, and there are some changes with which I do not agree. I do not want to question the decisions of the developers that maintained the project while I was not able to work on it (almost 10 years now) and that's why I think it is best if they are kept separate.

That being said, I appreciate all the work and the open-source spirit of keeping Krumo alive all those years, as well as all the other similar projects that have spawned in that period. It is one of the finest compliments for a developer to see that someone else appreciates their work.

[scottchiefbaker]

I respect that...

I'm a little concerned about the namespace though. There have been consistent updates over the years, and version increments, while the original went stagnant.

There is even specific wording about the original project being abandoned. If there are two competing projects with the Krumo name, with different versioning schemes that will definitely confuse users.

Both projects come up in the top 3 results when you google for "krumo".

[kktsvetkov]

Probably the best way to solve this is if I create a new iteration of the project, let's say 2.*, and you continue the 0.* releases. What do you think ?

[scottchiefbaker]

Since we're both going in separate directions, it's probably best if one of us changes the name of their project? This will avoid confusion, and help people googling $project_name.

[kktsvetkov]

Well, speaking of users: changing the project name will probably also mean changing the class name, and there is a lot of existing code that references 'Krumo'. The different version releases approach still seems like the better option.

[kktsvetkov]

@scottchiefbaker I've done some more thinking on this topic. As I said I find a few questionable things in the changes made over the years. Surely there are things which seem odd to you as well. I understand that a quick overview of the code is not enough to pick up all the context and nuances behind the decisions made. We can discuss the divergence in the code base, and perhaps I can try to convince you that some features can be done better, or you can convince me that some of those changes are needed just as they are. In this way, we can narrow the gap between the two repos and consider how we can indeed combine our efforts.

I'll try to find time to post comments on few of the topics I disagree with and see what the feedback is.

[scottchiefbaker]

Yes I think that's a good idea. I'd like to come to some middle-ground and then we can team up. Everything you've submitted thus far has been great. There is a lot of legacy code in Krumo that I just never bothered to upgrade. For the most part "it just works (tm)" and I don't sweat it.

I'm open to any suggestions you may have.

[scottchiefbaker]

Where do we stand on this? What's the future of both of our projects?

[kktsvetkov]

I have a lot of thoughts, but I don't have an answer yet. I do want to improve the library, which is still more or less a PHP4 project dressed as PHP5. It is a product of its time, and its structure and approach are very 2007-ish. For me, there are a lot of lessons learned from all the Krumo clones and all the development work put into them. I think I can do a better job now, and offer a library that is more flexible, more extendible, with better performance and more developer-friendly.

That's why at the moment I am more and more leaning towards doing a Krumo 2, and leaving you the maintenance of Krumo 0.* version (e.g. Krumo Legacy). I'll be contributing to the Krumo Legacy project any features and ideas I have that are doable with class.krumo.php as it is. Some of the ideas I have will require heavier refactoring and that might cause issues with people using current latest version, and that's why I think it is best if I do that separately in new iteration of the project, e.g. Krumo 2.

I am not entirely sure how the same project name can be handled by two separate repos. One idea I have is to create a "krumo-php" Github org, and have it host both projects with different names, let's say krumo-php/krumo2 (my repo) and krumo-php/krumo-legacy (your repo). I think I am going to create the krumo-php org anyway since it will be a good way to organize some of the associated projects as well, like bridge integrations or extensions (such as the heavily discussed krumo-search, which has jQuery dependency).

If you have some input into this, please do share it. Please share if you have input from other contributors to your project. As I wrote earlier I appreciate all the work done on the Krumo fork over the years and I do not want to do anything that will denigrate these efforts. In the same time, I do want to evolve Krumo into a modern library, and I am not willing to give up on Krumo.

[scottchiefbaker]

If you want to collaborate on a single Krumo source tree I would love that. I think that's a in the best interest of all the users, that have been using Krumo for years.

If you want to create a "Krumo 2.0" that does things differently I would respectfully request that you change the name so there is no confusion between the two projects. Krumo has a 10+ year legacy at this point, and having two projects with the same name will just create confusion.

[kktsvetkov]

I'll respectfully decline that request. Changing the name of the project is out of the question. I am the original author of the project, and I will continue to use the name "Krumo" for it. Your project is a fork of my work, and if you want to you can continue to use "Krumo" for your derivative work. You can also choose not to use it and pick a different name, as it is has happened to a lot of forked open-source projects.

I don't think there is any confusion, because your project states that it is a fork of Krumo, with updates, and not the original. As for the best interest of all the developers, I think it is better if they have a modern present-day library instead of a 13-year-old PHP4 class. I hope that in the weeks and months to come I will be able to show my work on Krumo 2 and convince you that the old Krumo is a thing of the past, and there can be a new Krumo that is better, faster, and more flexible.

[kktsvetkov]

BTW, I've joined Github in 2011. The oodle/krumo repo was created on Nov 14, 2012, and you joined the project (e.g. your first commit) was almost a year later on Sept 4, 2013. It would've been nice if you have invited me to your project around that time instead of stating:

... Kaloyan was the original author but he's not active

https://github.com/mmucklo/krumo/pull/4/commits/9a391369119f0d7646853145161e1c474bb31be1

I was never contacted by any of the collaborators of that project, and I was never asked to join. Not in 2013, not in any of the years later. I would've been happy to join and collaborate, or even just invited to witness the development of that project. And it is not as if I've been hiding - I've added comments to several issues in your repo in the last 2-3 years.

Now, it appears as if you decided to contact me only after you found out that your project appeared second on the google search for Krumo between my site and my repo. Not cool. And the reason to contact me it seems is that you want me to change the name of my project. Not cool at all.

[scottchiefbaker]

Whoa whoa... slow down. I did not even know you were the original author until 5 minutes ago. No malice intended here man. If it's your project then by all means keep it. I look forward to seeing what you come up with for Krumo 2.0.

[kktsvetkov]

LOL, what do you mean by "5 minutes ago"? I mentioned it in the first reply to this thread:

... I do not want to question the decisions of the developers that maintained the project while I was not able to work on it (almost 10 years now)

And the Krumo site http://krumo.kaloyan.info/ is on my domain and it references my repo

The modern way: use Composer. php composer.phar install kktsvetkov/krumo

And last, I go by my name here which is the same name as the @author tag in class.krumo.php

@author Kaloyan K. Tsvetkov <kaloyan@kaloyan.info>

You yourself even put @original before my name in the https://github.com/mmucklo/krumo/commit/9a391369119f0d7646853145161e1c474bb31be1 commit :) All that time I thought you did know that I am the original author of Krumo, and that's why asking me to give up the name was such a not cool thing to do.

[scottchiefbaker]

I didn't put two and two together. If you're the original author you're entitled to the name 100%.

At the end of the day all I care about is having a good PHP debugging tool. Right now, that's my fork of Krumo (I'm sure other people disagree). If you're back and willing to work on Krumo 2.0 then by all means go for it.