The Road to Collaborative EditingThe announcement that the PureBasic IDE has become available under open source via GitHub is indeed great news for everyone in the PB community, and especially so for those wishing to contribute to its growth.
I can understand the overwhelming joy to this announcement, and that many developers here are eager to starting tweaking the IDE sources and implement their long-desired features.
But, if I may, I’d like to drop a couple of words of warning regarding this, for I hope that Fred’s initiative to open source parts of PureBasic source code is going to alleviate some maintenance burden from his shoulders and allow the community to improve the IDE and add new features to it.
In order for this to happen, collaborative editing needs to be organized in a well structured manner. Version control in general, and Git and GitHub (in this specific case) were designed with this specific goal in mind, i.e. simplifying collaborative editing of the same code base without introducing complications due to different contributors working on the same files across different OSs, editors and IDEs.
GitHub offers a rich plethora of tools to make this happen in a smooth way, and there are many standards and workflows out in the wild to aid collaborative efforts in a well structured and constructive way.
A point I’d like to stress (having cloned and studied the new
purebasic repository) is that the project, as it currently stands, was clearly not designed with massive collaboration in mind. In other words, the shift from PB IDE development from a small group of coders to the open source realm might require some adjustments to prevent chaos creeping into the project.
As an example, those of you who looked closely at the PB sources on GitHub will have noticed that they don’t have a BOM. If you open those files and save them in UTF-8, the IDE will automatically add a BOM to the file, and Git will see the file as changed and expect you to commit them (even though no real contents were changed). On the other hand, if you handle the file in PB IDE as Ascii, you might corrupt some UTF-8 encoded strings without realizing it. This is just an example of how different people working on the same code with different editors or IDE settings could end up disrupting the source files in many subtle ways, often without realizing it (until it’s too late).
Surely, there’s nothing new under the sun, and similar situations are rather common in open source development, and there are various solutions to handle them and prevent code disruption — in this case, enforcing code styles via
EditorConfig is currently a good way to preserve integrity of the project and allow contributors to work on the code using different editors and IDEs.
But there are many other problems and pitfalls that affect working with Git on PureBasic projects, ranging from choosing the right PB IDE settings (to prevent IDE settings from being stored into the source files) to ensure correct EOL normalization at check-in (without those settings, a Windows user could make the code unusable to Linux and macOS users by introducing
CRLF EOLs in the repository Index).
My appeal to the PB community is to take this great opportunity that Fred donated to us as a chance to create a true collaborative effort on GitHub. I’m aware that not every user on the forum is favourable to using Git, but if we truly want to be able to joint-collaborate on the PB IDE growth we need to use version control, and to do so in a well regulated manner by setting forth some coding and contributing conventions, enforcing them via continuous integration services, and then stick to them.
The challenge at hand is being able to fork the original (upstream) code base, implement our own changes and then
be able to integrate them back to the upstream source, and to do so in an orderly manner. Git and GitHub are tools that can greatly simplify large-groups collaboration on the same codebase, but if used wildly they might end up complicating life instead of simplifying it.
By donating to us access to the PB IDE sources Fred has done us a great favour, but we have to realize that the raw project was intended for a small group of people who had an agreement on how to edit the code, and that we need to enforce some standards that can make the repository more oriented toward the GitHub way of forking and editing — and that we shouldn’t expect this burden to weigh on Fred’s shoulder.
Unless we do that, we’ll end up creating new IDE features which might prove hard to integrate back into original codebase, adding more burden on Fred’s shoulders instead of relieving him from it. Rushing each one in his/her own direction, without commonly agreed development patterns, has proven to be counter productive in the open source world — which is why standards, workflows and tools were introduced.
So, while I understand the enthusiasm to rush and start editing the IDE sources, I hope that developers in this community will also consider helping the new born repository to acquire solid collaborative foundations, by contributing settings to enable standards for code styles, continuous integration and deployment, version control schemes, an efficient features tracking system, and other tools that will prevent the project from blowing up in our faces if and when contributions start to be really big.
This is the first truly great GitHub challenge for the PureBasic community, and if we take it on the right way it could be the beginning of a new era of users contributions to PureBasic, which could ultimately lead to a richer PB echo system and a growth in the language popularity attracting more users.
And I’m sure that if we manage to prove to Fred that donating to the open source parts of the PureBasic code is going to relieve him from maintenance burden, and allow the community to contribute back great features in a seamless way, there’ll be more PureBasic open sourcing to come in the future.