Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
idk, Hasbro likes money and an API would be pretty low hanging fruit tbh
It's probably more likely to happen due to Hasbro/WotC owning it. They're doing a fancy virtual tabletop. If that's to integrate with DDB, it's going to need a relatively stable API.
idk, Hasbro likes money and an API would be pretty low hanging fruit tbh
It's probably more likely to happen due to Hasbro/WotC owning it. They're doing a fancy virtual tabletop. If that's to integrate with DDB, it's going to need a relatively stable API.
Yeah you are absolutely correct.
What makes you think it'll be a public API though?
Rollback Post to RevisionRollBack
Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
Well dang, thanks for clarifying. That was pretty interesting and indeed I did not know the details as you have put it. Restructuring the monolith will take time, after all they don't call it "technical debt" for nothing. If you don't spend the time up front designing a good plan, and you don't invest the initial time to develop it well from the onset, you amass a codebase that requires more maintenance time and eventual refactor which in the longer run turns into a lot of money, hence "technical debt". Either you pay the debt, or you go "bankrupt" so to speak. Refactoring can be a fun exercise if you've got the appropriate funds to do it (which is usually a lot). It becomes a pain when budget becomes constrained, and then they squeeze to try and get it done faster with less cost, just repeating the cycle again. Godspeed to them.
That's a good way of putting it. I think of software as a kind of garden where you have to keep it maintained. Prune stuff, clean some, water some things. If you don't keep up with it, it'll as you say rot.
Technical debt is definitely real. Often times "cheap and quick" are preferred over "quality and cost". There's a project management triangle that folks point in times like this: scope, cost, time. If you increase scope, increase money and increase time, you get higher and higher quality. As we know, the time was likely limited as well as low cost which amounts to a lower quality product. One must manage those 3 things, the scope of the work, the cost and time that's associated to it to define expectations. When tackling technical debt, it would probably be good to scope out what all the actual pain sources are, analysis on the time required to refactor and what the projected costs are for the refactor and projected gain of it. That's probably the hard part in communicating to stakeholders, what's to gain for the pause in growth.
Or as we contractors say in our unrefined vernacular "Good, fast, cheap. Pick two."
Honestly, WotC has horrendous IT development and support systems and I don't think they could build a decent public API endpoint system or even maintain one that someone else built them.
*bump* where API?
Bumping this for a +1 to a public API
Hasbro owns this website now. Ain't happening.
Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
#OpenDnD
DDB is great, but it could be better. Here are some things I think could improve DDB
idk, Hasbro likes money and an API would be pretty low hanging fruit tbh
It's probably more likely to happen due to Hasbro/WotC owning it. They're doing a fancy virtual tabletop. If that's to integrate with DDB, it's going to need a relatively stable API.
Yeah you are absolutely correct.
What makes you think it'll be a public API though?
Leaving OGL 1.0(a) untouched and making SRD 5.1 CC-BY-4.0 is a great first step. The next is a promise to do the same for future editions. Here's a discussion thread on that.
#OpenDnD
DDB is great, but it could be better. Here are some things I think could improve DDB
Stable and public are far from the same thing. It's honestly pretty impressive how wildly WotC has misread their D&D Fanbase.
Well dang, thanks for clarifying. That was pretty interesting and indeed I did not know the details as you have put it. Restructuring the monolith will take time, after all they don't call it "technical debt" for nothing. If you don't spend the time up front designing a good plan, and you don't invest the initial time to develop it well from the onset, you amass a codebase that requires more maintenance time and eventual refactor which in the longer run turns into a lot of money, hence "technical debt". Either you pay the debt, or you go "bankrupt" so to speak. Refactoring can be a fun exercise if you've got the appropriate funds to do it (which is usually a lot). It becomes a pain when budget becomes constrained, and then they squeeze to try and get it done faster with less cost, just repeating the cycle again. Godspeed to them.
That's a good way of putting it. I think of software as a kind of garden where you have to keep it maintained. Prune stuff, clean some, water some things. If you don't keep up with it, it'll as you say rot.
Technical debt is definitely real. Often times "cheap and quick" are preferred over "quality and cost". There's a project management triangle that folks point in times like this: scope, cost, time. If you increase scope, increase money and increase time, you get higher and higher quality. As we know, the time was likely limited as well as low cost which amounts to a lower quality product. One must manage those 3 things, the scope of the work, the cost and time that's associated to it to define expectations. When tackling technical debt, it would probably be good to scope out what all the actual pain sources are, analysis on the time required to refactor and what the projected costs are for the refactor and projected gain of it. That's probably the hard part in communicating to stakeholders, what's to gain for the pause in growth.
Or as we contractors say in our unrefined vernacular "Good, fast, cheap. Pick two."
Honestly, WotC has horrendous IT development and support systems and I don't think they could build a decent public API endpoint system or even maintain one that someone else built them.
Another feature that would be incredible but we'll never see because the code base is a mess, to add to my list, oh well.