eTools Patch and Source Code

[Hollywood]

Actually, I think they got around this by seperating the GPL and OGL items. The GPL is the code, which simply reads data, a glorified parser with a dislay window if you will, and interprets it. The OGL section is the lst files, which are completely human readable and modifiable. Either can be distributed independently of the other, if you want to write your own lst files or an app to use existing ones.

If you mix the 2, i.e. intertwine OGL data in the GPL source then you could have trouble (older versions of pcgen fall here I believe).

Yes, I believe thats the crux of the matter, although I do believe its still a problem with the OGL rather than PCGen itself. However, there are ways around the problem PCGen or others like it may face. Simply release the data and any code, properly bundled in scripting or plug-in form, that pertains to the SRD under the OGL. The application that runs it could be closed or open source and under whatever license you want.

It could be as simple as: Wizards actually own the source code, and it was always a key deliverable of the "completed" project.

This is a standard industry practice for consulting, such as was done by Fluid for WotC. Surprised me that WotC even made mention of it at all publically.

There's virtually nothing "under the covers", as far as 3rd edition mechanics is concerned. That's the whole point of keeping it open

I didn't mean the data or your expression, through script, of the SRD mechanics. But rather what the scripting language used (sorry, have downloaded last version but haven't had time to look through it and can't remember if I had recognized the scripting language or not), the backend data store, etc. While I'll argue for a broader interpretations of how to implement thing, I have to agree that having the SRD mechanics in script [or as plug-ins that can be changed and run] and such, it might be nice to reach some accord between those interested in building RPG software [for D&D/D20/whatever] on similiar ways of doing thing so that program can be interoperable.

If you tell me *why* you don't like it, I could possibly do something with that. If you propose a solution (especially where you've considered that balance of different needs), then we're really cooking.

Never been a fan of one program trying to do it all. Personally, what I'd look for is a highly usable character maintance program, but one that could plug into a large set of suites, or not, as I may desire. So to me, having not to wade through all the other wizards or even having to deal with them is key. Not to mention, because I run either high resolution laptops or CRT displays, I want as much information packed in as possible and the ability to highlight information I consider important to myself. Also, trying to keep to the standards that most applications adhere too is important [and which RPM does better than a lot of apps].

I'm not in a rush to use anyone's simple because I have my own, and no it'll never be released as its an experiment to play with different technologies to see how they work together, that works for now. And actually may rewrite my current one using completely different notions or technology, which is one reason I'd be curious to know more about what you are doing so as to make sure one can use the other's data, and what not.

Unless a utility provides the ability to share data among the program's users, in my opinion, it is a substandard utility. If importing something causes the program to break, folding your arms and saying "not my fault" is not an acceptible answer.

I won't disagree with you here. I fully agree, that a tool such as eTools or CoreRules needs to be able to share data among its userbase. Word Processing would be useless if you couldn't share the Word docs with others.

And I do agree, that if your software comes equipped with an import until, it should not allow data imported to cause the software to malfunction.

However, that is not the same as using a technology, such as Access but could be MySQL or just simply XML [or lst in the case of PCGen] as the datastore and saying to your users, "Hey, we have opted to store data in with this technology or through this manner that is able to be modified by you, the end-user. However, we take no responsibility for any changes you make in such a manner."

Its like anything else you buy, if you use it in a manner that is inconsistant with the instructions, then any breakage is your problem [pending all sorts of frivoulous lawsuits of course].

Providing an easy out for the service rep is not the same as providing good customer service.

Is there such a thing as "good customer service"? I've never seen or heard of it practiced on a scale that WotC would need.

How customer service will be handled is something that should be considered when the product is being designed.

Sure, thats a factor. But there are lots of other factors too, that drive how a product is designed and what technology to take advantage of. And you must weight those factors as you feel appropriate.

I was the project manager. I am also the president of Evermore.

Ok, that jives with your comments and I can see where you are coming from more easily. I think you realize I come from the architectural/development side of things.

P.S. Nice mix of technical skills... for a moment, when I saw Allaire JRun [which of course ya know is now Macromedia JRun and is a decent mid-tier J2EE server] I was expecting ColdFusion to be listed; thankfully its not....

 

[Hollywood]

My pastor asked me once why the font he was using looked all screwed up on his monitor. The first question I asked was "have you installed anything on this machine since it last worked?" He said that he had not.

Half an hour later, he asked if it could be related to the new fonts he had copied onto the machine the day before...

I think this sort of behavior/level of knowledge is more typical of the average user than what you describe.

Oh, I'm well aware of the that situation... I think anyone who is proficient with computers and has friends who are not that ask questions has heard responses like that.

But that brings up the point, just by copying fonts over, something happened. But who is at fault and who takes responsibility? The maker of the OS? the creator of the fonts? the end-user? Unfortunately, because customer support by its nature is very limited [you can't have your architectures, project managers, and developers working as customer support people... you'd lose a lot of money], you have to draw the line somewhere. At some point you just have to say, "if you did X, we can't support it any more."

Look at the electronic gaming scene; plenty of game software for the PCs that allows both developer made modifications and 3rd party hacks. In just about all cases, currently that is as it was different a few years ago, customer service just won't deal with these types of issues.

But anyways, I think we have really digressed off topic... sorry 'bout that!

 

[Bacrof]

But that brings up the point, just by copying fonts over, something happened. But who is at fault and who takes responsibility? The maker of the OS? the creator of the fonts? the end-user? Unfortunately, because customer support by its nature is very limited [you can't have your architectures, project managers, and developers working as customer support people... you'd lose a lot of money], you have to draw the line somewhere. At some point you just have to say, "if you did X, we can't support it any more."

I think the point was that getting the user to say that they did X is very difficult. They may not be aware that they did X at all.

Until you know that the user did X, you have to assume that it is a problem with your software.

 

[Hollywood]

Until you know that the user did X, you have to assume that it is a problem with your software.

If you do that, you could be hunting for an insolvable bug for quite some time. As contradictory as it may sound, and even to the point of seeming to ignore the end-user's actually complaint, its better to make sure of what external causes may be present before turning to issue within the software.

Customer support is a two-way street. Good customer support, if there is any out there, wants to remain supportive of the customer, but must in turn be able to provide as much information to the code maintenance staff as possible to be able to find and squash said bug [if it exists]. The maintenace staff won't be happy at all if the customer support staff continually logs issues that are caused by external software, files, etc. that are completely outside of either their control or outside of the limited support box they are working under.


<shrugs> but anyways...

 

[Arnix]

Wow, sounds like you have dealt with the company I work for's help desk. At least until we created forms for them to fill out with a list of questions to ask.

 

[Bacrof]

If you do that, you could be hunting for an insolvable bug for quite some time. As contradictory as it may sound, and even to the point of seeming to ignore the end-user's actually complaint, its better to make sure of what external causes may be present before turning to issue within the software.

Customer support is a two-way street. Good customer support, if there is any out there, wants to remain supportive of the customer, but must in turn be able to provide as much information to the code maintenance staff as possible to be able to find and squash said bug [if it exists]. The maintenace staff won't be happy at all if the customer support staff continually logs issues that are caused by external software, files, etc. that are completely outside of either their control or outside of the limited support box they are working under.

Assuming it is an issue with your software does not mean you immediately send it to the coders. Far from it. Part of investigating an issue is trying to reproduce it under controlled circumstances. Just taking the step of saying "okay, what steps are you following to cause the crash" is approaching the issue as if it were a problem with your product.

I think you're skipping over the role of the support guys in your argument.

 

[Hollywood]

I think you're skipping over the role of the support guys in your argument.

No, Bacrof I didn't. Maintenance is another word for support. Nonetheless, I refuse to argue this point anymore because its going outside of the topic of this forum quite drastically.

 

[ddavison]

I expect that community would quickly convert the access portion

...or MSDE instead since it ports easily from Access (being a Microsoft product), is freely distributable by MSDN Universal Subscribers, and allows almost all the features of full-blown SQL. Also, the front-end utility (SQL Enterprise manager) is free for end-users to install and use since Microsoft's licenses aren't tied directly to SQL Enterprise Manager, but to the SQL Server in the form of processor licenses or CALs.

Anyway, while I despise Access for most business use databases -- mostly because of poor multi-user capabilities, speed, etc. -- I think it was an acceptable choice for a single-user application.

Really though, advanced users could hit the data so long as they stick to an ADO compliant data source.

 

[Fast Learner]

Umm... what license for Access? You don't have to purchase a license to distribute an .mdb file. The file is simply being utilized as an ADO datasource that isn't using any specially-licensed DLLs or anything.

I don't see any reason to take it out of Access if the code actually opened up (which I don't believe will ever happen).

 

[Fast Learner]

Erm... ODBC. But you get the point.