dynambee

Fair enough. I've removed that message. It was just frustrating to take the time to write up a detailed report with specific examples and screenshots, and then ... nothing.

Thank you for at least replying and letting me know. In the meantime I have worked out a solution that works around the problem for my particular situation. Thanks for all the work you do on Chex and other modules, I hope to buy more stuff from you in the future.

[removed]

Did anything ever come of this discussion? Is @lesley okay? What is the status of TB?

@Havouza, it is fantastic to see you back in the forums. I hope you're well.

@datakick, I realize you're a busy guy but could you at least comment on my bug report and feature request?

Bug report / feature request: I've noticed an inconsistency in the way that Chex is working with regards to the selection of states in addresses, and I have a request for how to fix this. I am running the latest version of Chex, 0.7.0 as of this writing. The issue: At the start of the checkout process in the "shipping and payment method" section when you choose a shipping destination country, if that country has a list of states then a default state will be auto-selected. The default is the first state in the list. Like this: When you move further into the checkout process the collapsed "shipping & payment method" section looks like this: However, when you get down to the "Personal details" section, the country & state selection looks like this: As you can see above, no default state is auto-selected. Furthermore, once you select "Australia" (or any other country with a list of states) in the "personal details" section the "shipping and payment method" section changes to show the country instead of the state, like this: Requested solution: Please do not have a default state selected in the "shipping and payment method" section. Alternatively, please allow shop owners to select if they want a default state to be chosen and then have that preference apply in both sections of Chex. The reason I request this particular solution is that some shops will require a state to be selected in order to calculate shipping charges while other shops do not require a state to be selected as the cost is the same for all destinations within each country. Allowing shop owners to select this allows for maximum flexibility during the checkout process. I hope I have explained everything well but if I haven't please let me know and I will be happy to clarify with additional screenshots as needed.

Forking, by definition, means the project is split and there is a new project created. The new project is not TB any longer but some other new project. The only thing the new project gets is the open source code. Code is a lot, but it's only a small part of what TB is in total. If @lesley is going to hand the name, forums, blog, website, knowledge, social media, etc etc etc to "the community" or to some new entity then there is no need to fork because obviously in that case the existing repository would be part of that hand over.

The valuation on paper is probably more than any of us can afford to pay. Startups with customers & a functional system tend to be valued quite high -- again, on paper. The actual valuation is what someone is willing to pay. Sometimes there are very big differences between the two. Sometimes the first is very high and the second is zero. Other times companies way overpay for acquisitions if the target is for some specific reason worth more to THEM. With TB it probably depends on what @lesley wants to see happen to the project and if he see himself being able to come back and take the lead again sometime soon.

You really don't seem to understand. If we fork we GET this: ThirtyBees code ThirtyBees' modules' code If we fork we LOSE this: ThirtyBees name ThirtyBees website & SEO ThirtyBees branding & design ThirtyBees forum (including all users and multiple years of existing knowledge & content) ThirtyBees blog (including all knowledge, posts, and discussion there) ThirtyBees social media accounts ThirtyBees supporters platform & all existing supporters ThirtyBees modules & themes store (which I think was a custom build on top of a TB website) ThirtyBees existing installed user base -- there is no guarantee that any of them would move to a new & known to them platform ThirtyBees partners, of which there are quite a few and that took a LONG TIME for ThirtyBees to build up. Probably a whole lot more that I am forgetting to include here All of that would be GONE and need to be REBUILT FROM NOTHING. It's a massive undertaking. Also, while a fork would give us the code, it would still need modification. Currently all error messages and branding show the ThirtyBees name. This would all need to be fixed. It's not a simple "search and replace" either as there are many copyright notices in the existing code that would need to be maintained. Forking doesn't invalidate the TB copyright for existing work. The included themes (community & naria (sp?)) would need to be modified and changed to the new branding, too. So while forking does give the code it gives NOTHING ELSE. I can understand that to many programmers the code is "everything" but I promise you there is much, much more to a successful project than just having the code.

Correct. why? I'm sorry, but did you read my previous post at all? There is a huge amount of work that would need to be redone from scratch if the project is forked. Website, SEO, blog (all existing posts & knowledge gone), forums (all existing knowledge, discussions, & users lost), social media, module shop, existing supporters platform, etc. If it is absolutely necessary to redo all that work then fine, it has to be redone. I'm curious though, are you volunteering to pay someone to do it? I expect it will be quite expensive to duplicate the level of branding & design that already exists, and yes, branding and design are important if one wants to be taken seriously as a business, project, & platform. Personally I don't think it is a good idea to reinvent the wheel unless there is no way forward that can save all the existing work. Edit: I'll also add, a fork would mean needing to redo the existing core themes and edit the codebase to change everywhere the TB name appears to be the new name. This may sound trivial but it took ages for TB to get that right. I think even now there are times that PS pops up where TB should be instead. It's just more work that needs to be redone, duplicated effort. Starting with a completely existing platform means all effort can be spent on pushing the project forward. Forking means a huge amount of effort has to be wasted to redo work that has already been done once.

Forking would be a last resort, IMO. It is time consuming and expensive to establish a new brand and rebuild everything from the bottom up. It would be better to keep the existing brand, website, forums, repos, module shop, supporter payment system, (and more) in place. If there is absolutely no way to work things out and keep the existing structure then a fork and rebuilding can be considered, but it's an immense undertaking.

So to be clear the $50/month isn't specifically a license but more like a membership that lets you have some input into the direction the project takes, correct? I assume the money would be used to pay for development? Who would manage the money? Assuming things are set up well I'd be willing to contribute $50 a month.

Trying to modify the core like that will lead to unexpected consequences for some users. You should implement this as a module.

I'm not sure of your situation, I can only tell you about mine. I have three standard options: Slow, but very cheap. No tracking, no insurance. A little faster, has tracking, basic insurance. Middle price. A lot faster, better tracking, more secure, can be insured up to $20k. Highest price. If someone buys a $2 item I don't care which shipping they choose. There is no need to stop them from choosing better shipping if that is what they want, if they are willing to pay for it. If someone buys a total cart value of $50 I don't care if they choose option #2 or #3 but I don't want them to have #1 as an option. Again, if they want to pay for faster shipping then #3 should be available to them. If someone buys a total cart value of $200 then I only want them to be able to choose #3. This is why I don't need a minimum price.