Moving GUI Projects

[CharliePoole]

[I'm planning to continue to work on the nunit-gui in the future, separate from the NUnit Project. This is for various reasons, among which are...

• I think a bit of separation will help both me and the NUnit team move in our different directions a bit more smoothly. The gui will be one of my biggest focuses so, even though I plan to continue on the Core Team and contribute where I can, I'll be a bit more out of everyone's hair - and vice versa. 😜

• I'm going to apply some different policies to the GUI that could conflict with other NUnit software projects. In particular, I may end up using GPL as the license.

• I'm possibly going to do something commercial that ties in with the GUI, which will be easier if it's elsewhere. If I do that, it's possible that I'll end up with an open source "lite" version, which could be a candidate for contribution to NUnit, but it's a bit hard to predict right now.

• I'd like to get the GUI completely out of the competition among NUnit's various priorities. Of course, I will welcome continued collaboration from those who are already on the GUI team, but the choice of what to work on will rest with them.

Anyway, the typical way things like this are done is to do a fork. Anyone can fork and the power to do so is one of the two pillars of open source - the other is copyright. 😄

I prefer not to do that... I'd rather make the move by transferring the two GUI repos, nunit-gui and nunit-project-editor to my own account. Benefits I see of doing it this way...

• All the GitHub stuff (not just the source) comes with it: issues being the most important.
• Users are redirected. When they follow a link to nunit/nunit-gui they end up at charliepoole/nunit-gui.
• It will be clear to users that this is not a fork due to some conflict, but something we agreed to do.
• Users will not be confused, waiting for new releases in the wrong repository

This approach, BTW, is how I have been assuming we would handle any of our archived projects, if somebody wanted to take them over. It's the smoothest for users and gets the project out of our hair.

Also BTW... I'll shortly send the Core Team members an email giving a bit more info about some future plans I have that don't fit here.

[CharliePoole]

Forgot to mention... regarding timing... if you agree, I will do this right after the 0.4 release of nunit-gui.

[CharliePoole]

One more forgotten bit... details of implementing this, beyond just doing the transfers will be discussed with the existing gui team, but I can't write the issue until we decide pro or con the use of a transfer rather than a fork. 😄

[ChrisMaddock]

Given you've solely led the GUI project Charlie, and I think it's prospects look brightest under your direction, I don't think we-the-NUnit-Organization should stand in the way of this move - but I'm a little uncomfortable that you feel the need to move this out of the organisation, to take it where you want to.

On your points above:

1. I think only you have the understanding of how you feel there, so that's not up for discussion!
2. I'm not sure how changing the licence would relate to a need to move the project out of the organisation - if this were to remain an organisation project and 'the project lead' wished to do that, I'd envisage that being a separate discussion with the core team
3. I agree a commercial product would not be a good fit for the organisation at the moment.
4. This, I also feel shouldn't be an issue - we ARE struggling with workload/priorities, but I see the GUI as a separate project - I believe it's only yourself out of the 'key projects team' who actively works on it.

In summary, I think the prospects for the GUI project look brightest under yourself - and if you think that's best outside of the organisation, then I don't think we should stand in the of progress on the project. I think it's a shame however that you feel that needs to happen this way - and it makes me wonder if we're moving the organisation in the right direction. I do however think potential commercialisation is something that wouldn't work with the organisation currently.

There's a few active contributors to the GUI project. It would be interesting to hear their thoughts, if you're willing to bring them in to this discussion?

[ChrisMaddock]

I'll be succinct.

I'd support a transfer over a fork, as I think that's the best option for the wider NUnit eco-system. I think it's a shame that this seems necessary.

[CharliePoole]

@ChrisMaddock Thanks for your comments and your support.

I guess I want to put this in a different perspective for you. Splitting into many projects was the goal I started working for around 2009. That's why NUnit has layers and that's why we haven't had a GUI till now. The idea of not splitting but instead having a sort of federation of projects called the NUnit Project came up more recently.

I don't think that the fact that I feel a need to do the GUI separately says anything bad about the NUnit Project and the direction we are moving to organize it. A lively, dynamic open source ecosystem is supposed to enable such things. Stuff moves in and out of projects and they reciprocally influence one another in various ways. There was a time when the founder of the Gallio project claimed that by not joining with them, NUnit was hurting the overall .NET open source ecosystem. That was not true then and it isn't true in this instance either.

WRT including the GUI team in the discussion, I think that's just going to confuse people. Nobody outside of this team knows much about our reorganization yet and we would have to first explain the whole thing for them to make sense of it.

[jnm2]

The projects are already separated. We typically talk about the benefits of moving projects to the NUnit org. Can you help me understand what the benefits are of distancing the GUI project from the NUnit organization?

[CharliePoole]

@jnm2 Don't the four points I listed tell you why I want to do it? Which ones need more explanation?

[CharliePoole]

@jnm2 "We typically talk about the benefits of moving projects to the NUnit.org"

Actually, in our discussions of governance, I've tried to talk about the fact that many projects may not benefit at all from such a move. I have suggested that we should take in a contributed project only if it was of benefit to both the NUnit Project and the incoming project. To be honest, my impression was that it was simply assumed to be of benefit. 😕

[jnm2]

@CharliePoole I don't yet see a concrete reason why we wouldn't keep it in the org and achieve your goals. For 1 and 4, I'm already ignoring the project because GUI work isn't my favorite and there's other work to be had. For 2, why not just change the GUI project to GPL while it's still in the NUnit org when and if the time comes? For 3, you'll want a second org anyway for a commercial product. Why not wait to make the move till you actually change the license to proprietary?

My philosophy would be to cause the least upheaval necessary and continue towards the goals in all 4 points without moving the repo until a concrete reason shows that the move is worth it.

Also, 2 and 3 seem fairly mutually exclusive. I'd rather not make changes of this nature when knowledge of the future is so tentative.

[CharliePoole]

@jnm2 Just so I understand... your points are about my primary decision to no longer develop this as a part of the NUnit Project, which you would like me to reconsider - right?

I really hesitate to go too deeply into my reasons, because it would be very easy for them to be misinterpreted as a criticism of you and others or the direction the project is going. There seems to be a little of that in @ChrisMaddock 's reaction.

However...

All the things you say are things I considered in making my decision. As I have been considering it recently, the question in my mind has been when to do it, not whether.

A separate gui project has been one of the aims of the changes in NUnit that I started making in 2007, when I presented a diagram to the Mono gathering in Madrid showing it ending up that way. Our layering of NUnit exists in order to make this possible. I believe the gui will be better off separate and so will the key NUnit projects be better for its absence.

For me, the timing is right now because the changed organization of the NUnit Project now frees me to do what I have wanted to do all along.

Naturally, as an owner of the GitHub NUnit organization, I could have simply moved the projects. However, that would go against the kind of democratic governance we are trying to establish, so I asked for your views about doing it that way.

To my mind, a fork is only preferable if somebody else is going to take on the gui project under NUnit. In that case, the two projects would have to compete both for users and for contributors.

[jnm2]

Alright. There's a lot more backstory than I was aware of. =)

[CharliePoole]

@jnm2 Of course, you weren't around! 😄

Even so, many people who were around might only be aware that I think it's a good way to go for the benefit of NUnit and the open source ecosystem. My personal desire to do some projects on my own has arrived only recently - a few years.

I hope you and everyone can see that as just a matter of life changing and my feeling like doing other things. Like 26 years ago I moved from Seattle to the country. Now I think I want to live in a town. Neither the city nor the country should feel insulted. 😄

[rprouse]

This has been the plan for a long time, so I don't have anything to add except that I think a transfer is the best option.

[CharliePoole]

With the comments so far, I'm going to start an issue for the details on nunit-gui. Everyone should feel free to participate, of course.

[CharliePoole]

I created wiki pages on both the nunit-gui and nunit-project-editor repos. Our docs repos still has the same pages. I didn't want to make any changes without hearing how you guys want this to be handled in the wiki. In my mind, this serves as a test case for other separated projects with which we want to link.

Keeping the pages doesn't make sense, since they won't be getting updated as the applications change. Alternatives I can think of are

1) Just replace the current menu items with links to the other wiki

2) Create a heading at the top level for "Other" or "Related" applications and put the links under that heading.

I'm glad to implement whatever is decided, but I don't think I should be the one to decide.

[CharliePoole]

At this point, I propose to delete the Gui Team. What do you all think?

[jnm2]

Yes, not sure what we would need it for now.

[CharliePoole]

Maybe it's a no-brainer. It no longer gives you access to anything except docs and resources.

[jnm2]

Let's delete it and if lots of people need access to docs and resources, we create a team for that.

[CharliePoole]

I think most teams have access to those. I'll remove.

[ChrisMaddock]

Keeping the pages doesn't make sense, since they won't be getting updated as the applications change. Alternatives I can think of are

1. Just replace the current menu items with links to the other wiki
2. Create a heading at the top level for "Other" or "Related" applications and put the links under that heading.

2 sounds the most sensible to me, although I feel like that could be a list that grows. Although I'm not sure that's a problem. 😄

[rprouse]

I think either solution is fine although 2 gives more options to add more info if needed.

[CharliePoole]

I'll go with 2. It's easy for anyone to change, so I'll just do it.

@ChrisMaddock I'm pretty sure it wouldn't be a problem. :smiley:

[CharliePoole]

It's hard to show you what it will look like without doing it - so I just did it. Please look at the various sidebars in each project and at home. If Home looks OK, I'll change README.md to match it.

[rprouse]

Looks good to me. Only suggestion is maybe change the title to Related External Projects?