twinBASIC Weekly Update

twinBASIC Update: December 10, 2023

Highlights include an extended discussion on the possibility of open-sourcing some or all of twinBASIC in the future, plus a Linebreak Repair utility from fafalone.

Mike Wolfe

Dec 10, 2023 • 9 min read

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference. I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025. With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project. If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Here are some links to get involved with the project:

Highlights

Is the Future of twinBASIC...Open Source?

After several days of relative quiet on the twinBASIC Discord Server, Wayne let loose the following trial balloon:

Hello everyone! As we enjoy this festive season, I want to take a moment to connect with all of you on a topic that’s important for the future of twinBASIC. As we look ahead, I'm exploring various potential paths for our project. One intriguing idea, which is entirely hypothetical at this stage, involves a scenario where I might consider open sourcing twinBASIC. This would hinge on securing adequate funding to ensure the project's successful transition and sustainability. However, this is just one of many ideas, and I’m keen to hear your perspectives:

What are your initial thoughts on the possibility of open sourcing twinBASIC, with the understanding that it’s dependent on securing necessary funding?
Would you be open to supporting a fundraising campaign aimed at this goal?
Do you have any suggestions on how we might approach such a campaign, or other ideas to engage the community in this exploration?

It's a somewhat unconventional prospect and so I want to emphasize that this is a purely exploratory discussion. Your input is crucial in helping shape what direction we take, ensuring it aligns with the interests and expectations of our vibrant community. I'm looking forward to your thoughts, ideas, and feedback. Thank you for your unwavering support and for being the driving force behind twinBASIC. Wishing you all a joyful holiday season!

The discussion that followed was, honestly, a bit surprising from my perspective.

Criticisms of twinBASIC's Closed-Source Nature

One of the repeated criticisms of the twinBASIC project since its initial alpha release is that it is closed source. The reasons are many (and valid):

Closed source programming language projects are risky to potential adopters, especially when backed by a small team: what happens to the project if something happens to the main developer(s) or if the project itself is simply abandoned?
Requiring license fees to use the language blunts adoption, especially when there are many alternative languages that are completely free.
The subscription pricing model makes it harder to justify the use of twinBASIC for a one-off custom project, as the license would need to be maintained to provide ongoing support.
Every successful new programming language from the past twenty years has been open source (Ruby, Python, Go, Rust, etc.).

Wayne's Responses to Closed-Source Criticisms

To this point, Wayne has offered the following responses to the above concerns:

Once version 1 is released, Wayne has promised to place the source code in escrow, so that it gets automatically open-sourced (or otherwise made available to the community) in the event that something happens to him personally or he abandons the project.
The free community edition already provides very generous usage terms. For hobby programming use, it's difficult to argue the community edition is insufficient.
Very few paid modern software products provide perpetual licensing. Like it or not, the subscription model is where the industry is at right now. It also provides steady revenue to continue investing in the development of the language and IDE.

Discord Community Response to Idea of Open-Sourcing twinBASIC

Given the current state of things, then, I expected there to be full-throated support and excitement for the prospect of open-sourcing twinBASIC. On the contrary, most people who responded had two primary concerns:

Open-sourcing is a one-way trip. There are lots of potential unintended consequences. Wayne should think long and hard (and get specialized advice) before going down that road.
Development revenue could dry up. Open-sourcing the project could reduce licensing revenue, which in turn would reduce the profit motive for Wayne to continue developing the project.

In retrospect, I probably should not have been surprised to see this reaction on this particular platform. The developers who are active on the twinBASIC Discord server are those who are most invested in seeing the long-term success of the project and have already bought into much of Wayne's vision. A lot of the "twinBASIC can only succeed as an open-source project" criticism has come from places like vbforums.com.

My Thoughts: Look to B4A for Inspiration

Wayne should look for the right opportunity to open source twinBASIC, but not try to force it.

The B4A (Basic For Android) project from Erel is the best model for this approach.

B4A started out as a paid project. I bought a one-year license several years ago. It was a great piece of software that fully delivered on its promise of making it easy to develop Android applications using a BASIC-style programming language (as I recall, it transpiled from BASIC to Java under the hood).

I let my subscription lapse for two primary reasons:

I wasn't developing Android projects professionally.
The form designer saved form designs in a binary format that was incompatible with modern version control.

That said, if not for number one, I could have lived with number two. But I digress.

My point is that the software was good enough on its own–and it solved a specific problem (namely, writing Android applications in a BASIC-style language)–that I happily paid for the license. I think twinBASIC has a similar value proposition, though obviously it appeals to a different niche (namely, providing 64-bit support to existing 32-bit-only VB6 codebases and allowing VBA developers to easily create executables, Office/VBE addins, and other .DLL's).

B4A is also similarly developed primarily by one person: Erel Uziel.

Closed-Source B4A Goes Open-Source

Anyway, on January 22, 2020, Eriel announced that B4A was switching to an open-source model (emphasis in original):

So, the question is how to make B4X more popular? Obviously, it is not a simple nor a short-term task. A clear growth barrier is the fact that unlike most development tools today, B4A and B4i are not free. This wasn’t the case 10 years ago.

The big announcement today is that B4A will become free in a few weeks. The framework - set of internal libraries, will be open sourced.

We will accept contributions for B4A like currently done with B4J.
We've also secured funds from a US investor who shares my vision of making B4X a popular development tool. These resources will allow us to further expand.

For me, the key part of the above announcement was this line:

We've also secured funds from a US investor who shares my vision of making B4X a popular development tool.

Erel throws that line into his announcement as though it's a bit of an afterthought, but I suspect it was the real driving force behind the decision.

Honestly, it's reminiscent of my daughter's decision of which college to attend. After visiting a few schools, she had narrowed it down to two choices. One had a beautiful campus and great facilities, but required an extra year of schooling for her planned major and was significantly more expensive. She had her heart set on that school, though, until one day she suddenly changed her mind. She repeated back to us all the practical reasons why the less expensive school was a better fit after all (a conversation we had already had with her a few times). And then, as if this were merely an afterthought, she mentioned that her high school boyfriend was no longer going to the school nearby her first choice and instead would be going to a school nearby her second choice. Apparently, that was "also" a consideration. 😂

Open-Sourcing MUST Coincide with Major Corporate Sponsorship

My point is that Wayne should not rush into anything. If it were me, I would not open-source twinBASIC unless it were done as part of a major corporate sponsorship.

As others alluded to in the Discord chat, a major corporate sponsorship is not necessarily a pipe dream. If there is a large-enough company with a large-enough VB6 dependency, sponsoring the ongoing development of an existing future-proof VB6 replacement is likely more cost-effective (and certainly less risky) than building something in-house or migrating to another language (otherwise said migration would have happened long ago). Erel's open-sourcing of B4A under similar circumstances is proof that this is possible.

In the very near-term, I think a conversation with Erel Uziel would be the obvious next step for Wayne as he considers the pros and cons of open-sourcing (parts of?) twinBASIC.

By the way, the point of open-sourcing B4A was never about switching to a community development model. It was purely about providing peace of mind to the community. I expect the same would be true of any twinBASIC open-source effort:

Only the internal libraries are going to be open sourced and all the development will still be done by Anywhere Software. We might accept minor contributions.
The main purpose of open sourcing the framework is to let developers have more control over their solutions.

Discord Chat Summary

^{* Auto-generated via Claude-2-100k on poe.com}

General Channel

Here is a summary of the key points from the General channel transcript:

Intro:

The General channel covers a wide range of discussions about the development of twinBASIC over the past week. Conversations touch on syntax issues, project ideas, Advent of Code solutions, open sourcing considerations, and more.

Key Points:

Syntax and runtime errors encountered by users, along with troubleshooting suggestions from others
Sharing of small demo projects showing twinBASIC's capabilities
Benchmarking twinBASIC solutions for Advent of Code puzzles, with very fast runtimes compared to other languages
An in-depth discussion sparked by Wayne about potentially open sourcing twinBASIC in the future, with pros and cons debated at length
Considerations around funding models if going open source, including individual donations, corporate sponsorships, and paid "premium" features
Concerns raised about properly licensing an open source twinBASIC to prevent misuse while allowing contributions
Debate over whether open sourcing is necessary for twinBASIC's long-term survival and adoption
Anecdotes shared about use of VB6 and VBA in large financial institutions, suggesting possible enterprise licensing opportunities
General optimism about twinBASIC's progress and future potential, with v1.0 release expected to boost adoption

Summary:

The General channel covers all aspects of twinBASIC's ongoing development through thoughtful discussions. While an open source model has some strong supporters, concerns exist about sustainability. Overall, the community remains engaged and committed to helping guide twinBASIC's evolution into a modernized BASIC capable of preserving decades of legacy code.

Around the Web

VB6 GitHub Linebreak Repair

fafalone has released another twinBASIC project on Github, LinebreakRepair.

Here's his announcement from the Discord show-and-tell channel:

I've been downloading a lot of VB6 projects from GitHub to test in twinBASIC. When these have been uploaded with certain settings, GitHub replaces the vbCrLf line breaks with vbLf only, which results in a corrupt file that VB6 can't read. tB can-- but I need to confirm working in VB6 first. So I made this small project to automatically repair the line breaks of all VB6 files in a given directory, with a number of options to help. The file type list is preset, but you could change it to work on any file type instead.

This project uses my tbShellLib project for all the APIs (this is why the source file size is so large; however the compiled exe uses only what is neccessary, so is only 2MB). Can be compiled to both 32bit and 64bit. I've tested to confirm the output is byte for byte identical to using WinHex to manually replace 0x0A with 0x0D 0x0A, and the app checks whether the line breaks already appear to be correct.

See the project GitHub repository for more details on how it works, the .twinproj, a browsable source export folder, and binaries.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

No new releases this week.