Jump to content

CKAN Discussion Continutation


phoenix_ca

Recommended Posts

19 minutes ago, nobodyhasthis2 said:

I have got that hat too. Admittedly mine comes from another line of work. However the principles are the same everywhere at least. Sorry if that bit is unclear. I am honestly trying to put your analogy within the context of the CKAN project. As I currently see it. I am not a CKAN developer just a fellow end user. That might have shared some similar project manager experiences that you have. 

Hopefully this is an accurate summary. Please let me know otherwise. Not going to quote you. No point in repeating the whole thing. In short. Your right in general but the basic analogy you using above is slightly wrong. I do however like it overall. The outcome of your analysis is none the less mostly correct I think. Although I suspect in will be lost in translation for some.

There is no distribution here. It is a metadata index. Basically a list of download links. So it is better to think of it as:

1. Content creator.

2. Index system (Which is crowd sourced information and usually not related in any way to the content creator ). 

3. Content Consumers. ( which are in fact at best bug testers that might help group 1. Or can be safely ignored.)

I think you whole point is aimed at 2. Honestly in terms of actual volume of mods and downloads. This whole debate is really a storm in a tea cup in the grand scheme of things. It is actually about how direct problem traffic away from group 1 and 3. However the tricky thing those groups will not help. Or rather should not be expected to help. There are mostly not even aware there is any problem. 

Here is the main point. Group 1. Simply does not care at all about group 2. It is all irrelevant to them. There is no process to improve here from their point of view. They are not interested. Creating content is fun. Whist doing the indexing is not fun. In fact until recently there was still few individual mod authors packaging slightly outdated copies of module manager in manual downloads. Why?

Version checking is a group 3 job. That is what best bug testers are for and module manager is just another mod to manage. Version checking outside of owned mods has nothing to do with the content creators really.

So yes there is a slightly broken process in regards to managing the input and verification of indexing data for group 2. If you know how things work socially everything is all ok. Stuff gets fixed. If people come into the forums and direct wrath at a content creator instead. Bad stuff happens. It always goes from a polite "CKAN is not my problem". To "burn CKAN users at the stake" as they become more irritated.

 

 

 

 

 

Although a reconciliation between pjf and the development community can only come by their own efforts, I would submit that at least part of the solution would be a formalization of the control of that index.  A certificate which would constrain the control of an index entry to pjf and the developer of a particular mod might be a useful tool in developing a process that works effectively for all. 

Thanks for sharing your thoughts.

Link to comment
Share on other sites

21 minutes ago, mjl1966 said:

Sir, you have created a logo, detailed descriptions of your mods, videos, a Wiki and a donate button.  Your actions are not consistent with the notion that you do not have a sincere interest in sharing your mods with the user community beyond a casual coincidence of convenience to yourself. 

I did not create the logo, an artist created it for me a long, long time ago.

The descriptions are pretty short all things considered, not at all what I would expect from someone trying to get users.

I have not created any videos about my mods.  I merely link some useful ones that other people have made.

The wiki is a very, very poor attempt to get users to shut up about questions over features that I implemented for me.  It's a support-reducing measure.

The donate button is only there because enough people asked that I bothered.

These actions are consistent with wanting a small, manageable userbase for feedback and bug reports so I can better improve my experience.  The type of userbase that CKAN tries to bury with it's lowest-common-denominator flood.  I see no reason why I would want CKAN to create that mess for me, and one of the many complaints wrt CKAN is that its supporters and anyone trying to mediate always tries to sell CKAN bringing in more users as a good thing for modders to the same modders that don't want those users.

Link to comment
Share on other sites

Seems like a lot of this could be solved if maintaining specific NetKAN entries was the responsibility of a dedicated Maintainer position, perhaps the mod author, a nominated third party or a member of the CKAN contributors/staff. With one person in charge of a specific file, there is a clear place that the buck stops in case of stuff ups.

That means its slower to update than the current all open method. Possibly that could be combined with having a second main index, one for stable and one for experimental/recent updates. The maintainer could put updates to the experimental source, then say a week later move issue free ones to the stable source. That way would still be a little slower than present, but more than justified, I think - and it largely addresses RD's qualms over 'random guy off the internet' messing with his entries.

It would also be a step closer to the process that apt uses without these kind of acrimonious discussions.

Edited by blu3wolf
Link to comment
Share on other sites

What I posted WRT this discussion on the CKAN github (and one that I think plugs the holes).

 

1.  Before adding a mod, ask.  If no response, list away.  (gives modders a chance to say 'no thanks'.  I have done this in the past).

2.  If a modder ever comes back and says 'please remove this from the index' - regardless of reason - respect that.  Case in point, my own mods that I have deprecated (yet had some zombie CKAN data for a very long time).  Anther case may be where a modder sees a spike of issues, and they want out of the index till it can get sorted (like when @Angel-125 occassionally got clobbered with bad dependencies).

3.  Add a dev/staging repo and make sure the stuff is vetted first.  This may take longer to implement, but coupled with some automated tools, can help mitigate issues.

 

Note that all of these are modder centric.  As noted, 'market share' and 'exposure' are nowhere on my list of considerations.  Optimizing my enjoyment/annoyance ratio is.

Edited by RoverDude
Link to comment
Share on other sites

17 minutes ago, RoverDude said:

What I posted WRT this discussion on the CKAN github (and one that I think plugs the holes).

 

1.  Before adding a mod, ask.  If no response, list away.  (gives modders a chance to say 'no thanks'.  I have done this in the past).

2.  If a modder ever comes back and says 'please remove this from the index' - regardless of reason - respect that.  Case in point, my own mods that I have deprecated (yet had some zombie CKAN data for a very long time).  Anther case may be where a modder sees a spike of issues, and they want out of the index till it can get sorted (like when @Angel-125 occassionally got clobbered with bad dependencies).

The deprecated mods in question though, were if I recall correctly, released under a license where you made a guarantee to the users that you would not interfere with the distribution of them. Why shouldn't a mod index include old mods for those users who want to use them?

Link to comment
Share on other sites

I have no idea what guarantee you speak of.

The mods flat out did not work, could not be made to work, and had no value other than causing me a support headache, and causing confusion (since in some cases, they were moved to other packages and the old ones were completely invalid).

Normally, folks 'get this'.  When they do not, and just say 'tough, you chose your license', then we just move onto new licenses, simple as that.

 

Link to comment
Share on other sites

42 minutes ago, ferram4 said:

I did not create the logo, an artist created it for me a long, long time ago.

The descriptions are pretty short all things considered, not at all what I would expect from someone trying to get users.

I have not created any videos about my mods.  I merely link some useful ones that other people have made.

The wiki is a very, very poor attempt to get users to shut up about questions over features that I implemented for me.  It's a support-reducing measure.

The donate button is only there because enough people asked that I bothered.

These actions are consistent with wanting a small, manageable userbase for feedback and bug reports so I can better improve my experience.  The type of userbase that CKAN tries to bury with it's lowest-common-denominator flood.  I see no reason why I would want CKAN to create that mess for me, and one of the many complaints wrt CKAN is that its supporters and anyone trying to mediate always tries to sell CKAN bringing in more users as a good thing for modders to the same modders that don't want those users.

Very well, sir.  Thank you for your honesty. 

Link to comment
Share on other sites

1 minute ago, mjl1966 said:

Although a reconciliation between pjf and the development community can only come by their own efforts, I would submit that at least part of the solution would be a formalization of the control of that index.  A certificate which would constrain the control of an index entry to pjf and the developer of a particular mod might be a useful tool in developing a process that works effectively for all. 

Thanks for sharing your thoughts.

@politas has already mentioned all about project staffing. In short it is not really directly related to Pjf here.There is no big secret here it just not my place to say anything about pjf. I leave it for him to talk about future plans.

In terms of actual work load. It is not a lot for one mod and it usually only has to be done once. Usually. As far as mod authors helping. Simply put and mod authors don't care. Seriously mod authors do not want to do it. Your are giving them extra work and they don't want it. A lot of them don't even know how. They are under no obligation to do anything. Including providing the actual mods themselves. 

This is not hypothetical. There has been two occasions where a lot of mods vanished off CKAN. Where there was no update required by the vast number of modders. The first was in release KSP 1.0.4 (Sometimes it really is minor update). Fixed by global acceptance of 1.0.3 mods as compatible. Since the mod authors did not rush in and fix the metadata. After all nothing was broken from their point of view.

The second was the Kerbal stuff takedown. Fixed by the creation of Space dock and moving of FOSS licensed mods by group of lovely people. Then a painful process of finding all the 404 errors after mods where put back up by the authors and manually fixing them. Which was mostly done by only two people. From inside CKAN. (That is not to say it was all them. The statistics are available on Github if somebody wants to check the exact numbers of changes in that time period ) 

Now we could devise some elaborate method of control as suggested. However end users will still report problems to the mod authors who simply don't care. CKAN people do want the problems however there is a lot of feedback that goes to the wrong place. 

We can indeed talk about " A certificate which would constrain the control". Or start switching mods to an ARR licence to satisfy an odd policy statement. However open source collaboration is not down that road.  

 

Link to comment
Share on other sites

2 minutes ago, RoverDude said:

I have no idea what guarantee you speak of.

The mods flat out did not work, could not be made to work, and had no value other than causing me a support headache, and causing confusion (since in some cases, they were moved to other packages and the old ones were completely invalid).

Normally, folks 'get this'.  When they do not, and just say 'tough, you chose your license', then we just move onto new licenses, simple as that.

 

Well, that is exactly what you should do, if you dislike the implications of a specific license.

If you released an older mod under a GPL license, you made specific guarantees to the users of that product, about their rights to use, distribute and modify that work. Its possible I am misremembering, and that you did not in fact release those mods under a GPL license.

Im sure the threat implicit is that woe betide the community if you move your mods to ARR, but its not much threat tbh... and if you wanted greater control over the distribution of your mods, its something you should do. ARR on its own is not something that legally deters users from using your mods, but it does at least make it a little harder to ensure its survival. Of course, you have already made it clear that you have no interest in your mods survival, and that the point of releasing it is to ensure you get public bugtesting for your work. If that is the case, I have no idea why it wasnt ARR from the start.

Link to comment
Share on other sites

You might want to review some of my current licenses then.

GPLv3 to make PRs from oodles of contributors easier, some supporting dll's and art assets ARR.  Tho when people ask nicely (which they generally do), I share.  So really, it's a moot point.  

(addendum)

And if I get hit by a bus, I generally have an out clause that releases everything.  Because I actually would prefer not to leave users in a lurch.  That's just being a decent human being.  But since not everyone can play nice, restrictive licenses (or from my point of view... ask nicely first licenses) end up being the answer.

Link to comment
Share on other sites

29 minutes ago, RoverDude said:

What I posted WRT this discussion on the CKAN github (and one that I think plugs the holes).

 

1.  Before adding a mod, ask.  If no response, list away.  (gives modders a chance to say 'no thanks'.  I have done this in the past).

2.  If a modder ever comes back and says 'please remove this from the index' - regardless of reason - respect that.  Case in point, my own mods that I have deprecated (yet had some zombie CKAN data for a very long time).  Anther case may be where a modder sees a spike of issues, and they want out of the index till it can get sorted (like when @Angel-125 occassionally got clobbered with bad dependencies).

3.  Add a dev/staging repo and make sure the stuff is vetted first.  This may take longer to implement, but coupled with some automated tools, can help mitigate issues.

 

Note that all of these are modder centric.  As noted, 'market share' and 'exposure' are nowhere on my list of considerations.  Optimizing my enjoyment/annoyance ratio is.

 

That sounds like a proposal for discussion to implement an improved process to solve the problem.  Has pjf responded?

 

 

Link to comment
Share on other sites

35 minutes ago, blu3wolf said:

The deprecated mods in question though, were if I recall correctly, released under a license where you made a guarantee to the users that you would not interfere with the distribution of them. Why shouldn't a mod index include old mods for those users who want to use them?

I think the problem is distribution and installation, not licensing.  Currently, automated distribution results in a massive increase of erroneous distribution.  And it's really liquiding off the devs who have no control over how their mods are handled by that automated distribution.  So much so that some of them just want to shut the door and give the world the middle finger.  (I can sympathize.  Technical support sucks bad enough without automated workload that really could be avoided.)  I'm willing to bet that if they can get a hand in controlling what goes into the hopper, this whole thing can get resolved right quick. 

Roverdude says they're working on just that, so maybe some progress.

Link to comment
Share on other sites

21 minutes ago, RoverDude said:

It's under discussion now.

Well, there you go.  I hope it goes well; this problem is hurting the game.  We need happy devs. 

4 minutes ago, blu3wolf said:

Nothing preventing them from doing so.

The vocal minority so far seem frustrated at users, not CKAN. Its just CKANs fault that it happens to work as well as it does.

Yeah, we're the symptom.  Trust me, I know exactly how these devs feel when they get by bombarded by a bunch of support questions that are from something totally beyond their control.  I know Roverdude is a big ol' softy, but even he's barking.  That's bad. 

For my part, I know how to copy files and have even written some C# scripts in Unity, but I really do like CKAN for organizing things.  I think we're better off for it.  But we *must* have happy devs.  I really hope they can find some common ground on this.

 

Link to comment
Share on other sites

We'll see.  As it stands, the only way to opt out of CKAN is to move forward with an ARR license as that's the only circumstance in which they will de-index on request.  Let's see if they are willing to change that in the interest of goodwill.

Edited by RoverDude
Link to comment
Share on other sites

6 minutes ago, mjl1966 said:

Yeah, we're the symptom.  Trust me, I know exactly how these devs feel when they get by bombarded by a bunch of support questions that are from something totally beyond their control.  I know Roverdude is a big ol' softy, but even he's barking.  That's bad. 

For my part, I know how to copy files and have even written some C# scripts in Unity, but I really do like CKAN for organizing things.  I think we're better off for it.  But we *must* have happy devs.  I really hope they can find some common ground on this.

Well no, it isnt something completely beyond their control. They have as much control over it as anyone does, something RD has been demonstrating with mixed success.

Its not so much about copying files. Up to now, Ive been manually installing USI stuff and FAR, just so I can get support if I need it. Its more the chain of malice. Mod authors get more users than they want, because maintaining a modded install is a lot of work (time spent not playing KSP). They then figure that is the fault of the software letting users use their mods. Compounded in cases where CKAN metadata has been messed up, making those new users vocal about what they see as the mod not working. On the Trainz forums, they complain about gimme pigs. Here, its CKAN users.

I really think the best solution here is a set of CKAN repositories, being Stable, Experimental, and Unsupported. Saying that CKAN should delist mods entirely is a little like saying RD should delete all his mods.

Link to comment
Share on other sites

 

7 minutes ago, blu3wolf said:

Saying that CKAN should delist mods entirely is a little like saying RD should delete all his mods.

I don't even understand how this comparison makes sense...

But if the only request CKAN respects is in the form of a restrictive license (and i'm not sure they are going to budge on that), then that's what they will get, and I expect more modders to follow suit.  So the ball is in their court at this point.

Link to comment
Share on other sites

Just now, RoverDude said:

 

I don't even understand how this comparison makes sense...

But if the only request CKAN respects is in the form of a restrictive license (and i'm not sure they are going to budge on that), then that's what they will get, and I expect more modders to follow suit.  So the ball is in their court at this point.

To be honest, I feel like that is a mistake on their part. They should not discriminate between ARR and FOSS licensed works, WRT delisting mods.

They should simply not delist mods at all.

This would work best with various CKAN repositories, though. The present single source one is just not maintainable. Using a set of Stable, Experimental, and Unsupported repos would be the ideal fix for this. Rename the current CKAN repo Unsupported, then let modders opt in to the Experimental repo. Their metadata gets moved there, and removed from the Experimental repo. Give it a week or a month or whatever, and the metadata gets then moved to the Stable repo.

Set the CKAN client to be able to display mods from multiple repos at once, and by default only show mods from the Stable repo. Users who want to use Unsupported mods still can, and its immediately clear to them that they should expect no support with them.

Link to comment
Share on other sites

"To be honest, I feel like that is a mistake on their part. They should not discriminate between ARR and FOSS licensed works, WRT delisting mods. They should simply not delist mods at all."

Sure, then we just host elsewhere, stop modding, or take other actions that block CKAN (I mean, most of us are software engineers and it's not exactly hard), and good times are had by all, when a simple conversation and a bit of respect for content creators would have solved all of this.

Edited by RoverDude
Link to comment
Share on other sites

No, it wouldnt. Both the outcomes you propose are identical - not using your mods, or you not promulgating your mods.

That isnt a solution, not so far as the user is concerned. If its a solution for you, then you should do whatever you feel you need to, for your health and peace of mind.

If that was a serious thought on your part, echoed by all mod authors, all that would happen is a majority of users would stick to 1.1.2, much as there was a large portion of users with 1.0.5 and previous versions.

Link to comment
Share on other sites

Incorrect.  There are many avenues for mod distribution... forums, CKAN, Curse, SpaceDock, etc. - I like being able to control how these are distributed, and the contents of those distributions.  And this keeps support to a reasonable level.

But I respect that you have your opinion.  And I have mine.  

Link to comment
Share on other sites

6 minutes ago, RoverDude said:

Incorrect.  There are many avenues for mod distribution... forums, CKAN, Curse, SpaceDock, etc. - I like being able to control how these are distributed, and the contents of those distributions.  And this keeps support to a reasonable level.

But I respect that you have your opinion.  And I have mine.  

Then I would humbly suggest, that open source licenses are not for you.

I would also point out that a number of users do not have the time to set up an install of several hundred mods when those mods are sourced from a thread, or from Curse (aptly named)... but from CKAN, it suddenly becomes viable without spending days curating the install. For a subset of users, your mods not being on CKAN is equivalent to your mods not being available.

Also, after you went to the trouble of having your mods removed from CKAN, I might point out that several are still floating around. The Community Resource Pack, and the Alcubierre Warp Drive, are both still present - as are deprecated versions of Asteroid Day, FirespitterCore, ORS Fork, Regolith, Sounding Rockets, and USI Tools.

Link to comment
Share on other sites

Yep, that's the problem with CKAN metadata.  It is not reliable, and it causes support issues.  Despite handling my own data.  Other modders would agree.  And some of us would prefer not to be forced to opt into a broken process.  

Regarding how my mod's presence or lack therof on CKAN (or curse.. or spacedock... or whatever) makes it effectively not available.  I've been abundantly clear in the past regarding my position on that.  And the folks who wish to use it and be engaged with it and other users of the mod have many clear avenues to obtain it.

Anyhoo, this horse has been beaten into the ground.  We'll see what the CKAN folks have to say.  

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...