DragonByte Tech
Well-known member
I've already stated my opinion on the situation of "investing up front to develop addons" as opposed to the normal way of "you pay me, I deliver code to you, end of story" in the other thread, so I won't re-iterate that.
What I do feel like I should chime in on though, is the idea of supporting already developed add-ons under a similar scheme. There are two main pitfalls I can see with this system:
1) Who sells the addon on what site, and who controls the money?
2) What happens if the quality of the code isn't great?
In this post I want to add my perspective as to why I believe they can be pitfalls, and offer some potential solutions
I'll address the easiest first, #2. I have quite a bit of experience having to support other people's code, code that sometimes leaves something to be desired in terms of quality and coding style. I've also quite a bit of experience writing terrible code, although in my defence if I write terrible, hacky code it's usually for a reason
Joking aside, the point I'm trying to make is that every coder has their own way of coding things, their own internal standard, and taking over someone else's work may find that work conflicting with those standards. This is way less likely to happen on XF2 since, unlike vBulletin, XF2 has a rather standardised framework that mandates certain aspects of the quality of the code.
Potential solution: As these add-ons has the potential of going through multiple different developers, I would recommend that you mandate compliance with XF2 standards (e.g. resource guidelines & beyond), and potentially also look into paying other developers to peer review the addon. That way, you can ensure that the quality of the product(s) is as top-notch as possible, making the lives of you and your future developers easier
For the first point, as to who sells the product & controls the money, the TL;DR would be that you would need a very robust set of tools that gives your developer real-time indication as to when products are sold and how much they will be earning.
I would not recommend that the developer sells the tool on their own site, as that would lead to copyright problems and support expectation problems.
For instance, if Customer A purchased a product from us (DBTech), and then later we lost the reselling rights, where would the customer go for support if they encountered a problem 6 months down the line? Where would they go for updates?
Initially, they would come to us (DBTech), and then we'd have to tell them "no actually you need to go over there now, and then work out a way to port your license over to that site", which is a customer support nightmare.
Potential solution: For that reason, you would need to run & maintain the site selling the products, and you would (as mentioned earlier) need to ensure that there's no way either of you could hide payments from the other - you would need a way for the developer to see sales & projected income in real-time.
(Typing out that solution gave me an idea for our own eCommerce tool, but I digress.)
In summary, I hope this post helped in some way. It's an interesting idea, and I would love to know if it actually would work in practice
Fillip
What I do feel like I should chime in on though, is the idea of supporting already developed add-ons under a similar scheme. There are two main pitfalls I can see with this system:
1) Who sells the addon on what site, and who controls the money?
2) What happens if the quality of the code isn't great?
In this post I want to add my perspective as to why I believe they can be pitfalls, and offer some potential solutions
I'll address the easiest first, #2. I have quite a bit of experience having to support other people's code, code that sometimes leaves something to be desired in terms of quality and coding style. I've also quite a bit of experience writing terrible code, although in my defence if I write terrible, hacky code it's usually for a reason
Joking aside, the point I'm trying to make is that every coder has their own way of coding things, their own internal standard, and taking over someone else's work may find that work conflicting with those standards. This is way less likely to happen on XF2 since, unlike vBulletin, XF2 has a rather standardised framework that mandates certain aspects of the quality of the code.
Potential solution: As these add-ons has the potential of going through multiple different developers, I would recommend that you mandate compliance with XF2 standards (e.g. resource guidelines & beyond), and potentially also look into paying other developers to peer review the addon. That way, you can ensure that the quality of the product(s) is as top-notch as possible, making the lives of you and your future developers easier
For the first point, as to who sells the product & controls the money, the TL;DR would be that you would need a very robust set of tools that gives your developer real-time indication as to when products are sold and how much they will be earning.
I would not recommend that the developer sells the tool on their own site, as that would lead to copyright problems and support expectation problems.
For instance, if Customer A purchased a product from us (DBTech), and then later we lost the reselling rights, where would the customer go for support if they encountered a problem 6 months down the line? Where would they go for updates?
Initially, they would come to us (DBTech), and then we'd have to tell them "no actually you need to go over there now, and then work out a way to port your license over to that site", which is a customer support nightmare.
Potential solution: For that reason, you would need to run & maintain the site selling the products, and you would (as mentioned earlier) need to ensure that there's no way either of you could hide payments from the other - you would need a way for the developer to see sales & projected income in real-time.
(Typing out that solution gave me an idea for our own eCommerce tool, but I digress.)
In summary, I hope this post helped in some way. It's an interesting idea, and I would love to know if it actually would work in practice
Fillip
