It’s no secret, at this point, that Xojo is releasing its new Libraries functionality. This gives us something that we’ve been waiting a long time for, and means big changes for GraffitiSuite going forward.
So, what’s the plan?
As with any big change in the Xojo landscape, we’ve analyzed the various paths we can take moving forward to provide the best products and experience for our customers, as well as done some market research. What we’ve found is that most users want the ease of use of what Libraries will allow us to offer, while providing the intellectual property protection we’ve wanted for a very long time. Add in the fact that most customers seem to be quick to shift to new versions of Xojo, it’s a win-win to make this move as quickly as is possible. With all things considered, beginning with Release 65 — assuming a few minor, outstanding issues with Libraries are addressed — we’ll be supplying all GraffitiSuite products as Libraries.
What does this mean for customers?
Well, for one, no source code access. We did a survey a few years back that asked “How often do you need to view or edit the source code of GraffitiSuite?” The result was overwhelmingly (99% of respondents) “Never”. So, the vast majority of customers lose nothing that they were taking advantage of already. Now, there may be questions, given some fairly recent events, about what would happen to GraffitiSuite if something happened to Anthony. These are great questions, and a plan is in place. Should the worst occur, a well-known member of the Xojo community will take over the project with contingencies to open source if necessary.
What about bug fixes in support tickets?
That’s a sticky situation that we’re still working out the details on. We have three paths before us:
- Provide no fixes in tickets, but do full releases more often.
- Provide full rebuild fixes by completely rebuilding the libraries each time we need to send a fix.
- Continue our current release schedule but put out smaller releases for big issues.
Option number one carries the lightest daily workload but greater monthly workload. Instead of doing releases every three-to-four months as we currently do, we’d likely move to a monthly release cycle. This would, of course, reduce development time as we spend more time preparing these releases (which is quite a process) so it’s not exactly ideal.
Option number two is a cumbersome solution. Builds aren’t instantaneous, so development time would also be lost as we prepare these bug fix builds, potentially for one customer’s issue that no other user is experiencing. It’s not the best solution for either party.
Option number three is likely the best for all involved, and is essentially what we do now except we wouldn’t provide fixes in tickets and we would no longer do “point release” numbering. No longer providing quick fixes isn’t really desirable by anyone, but to ensure that we can continue to build new products and provide a high level of support to all customers, it’s probably the best solution. Of course issues may arise that require a build for a specific ticket, and those would be distributed as a full release as necessary. We’re ready for that reality, but it’s likely that fixes for relatively minor issues may be delayed.
What about projects in older versions of Xojo?
Similar to the Web 1.0 to Web 2.0 switch, those will continue to work with the older versions of GraffitiSuite that they currently use but for fixes or access to new features, you will need to upgrade unless we deem the issue serious enough to require a back-ported fix (which we did a number of times for Web 1.0 after the release of Web 2.0).
What about registration?
Over the last 22 years, our products have been distributed openly on the dark web, rebranded and sold by other developers, and more. With Libraries we finally have an opportunity to protect our IP from start to finish, and we have to take it — we will be moving to a registration key system. This will be similar to the system we had in place for many years when we distributed GraffitiSuite in encrypted format. During debug everything just works, but your built application must register GraffitiSuite with a key that is tied to your account and subscription expiration date in order to operate. This is also affords us the opportunity to again distribute demos in source code format so that users can see how to implement GraffitiSuite in their own projects, build their end product, then register when they’re ready to distribute.
Now, some of you may have concerns about the key being tied to subscription expiration date. You shouldn’t. These keys are versioned, so you should always be able to register GraffitiSuite using a key for a version of GraffitiSuite that was available when your subscription was active. Your built apps will never stop functioning because you let your GraffitiSuite subscription lapse.
Questions, Comments or Concerns
We understand that this is a big change, and big changes can be scary. As always, we’re ready to help you via our support system if you need us.