Rollance - User Hostile Open Source Software

Open source software can also be synonym with bait and switch, user hostility & plenty of bugs. There's no joy when your tools keeps breaking.

 · 6 min read

I’m writing this post for two reasons. First reason is to share the recipe for a software fix. The second reason is to share my humble opinion about what open source software developers should care more about; stability.

Too often open source developers think they are very clever by pushing new features. Software doesn’t age like physical things; C, Javascript, Linux, etc… are still as pristine as ever. Don’t drink the cool aid that new software is better software. This is what commercial software vendors want you to believe. Lisp is 64 years old today and I would feel more confident to choose this language than any language that got released in the past couple years.

Besides security issues, there’s really no reasons not to build any software incrementally. Many great open-source software (GNU/Linux, SQLite, Emacs) respect that. Some programming languages like Javascript, C, Emacs Lisp respect that philosophy as well. Those are softwares that are not hostile to their users.

The reason I’m talking about this point is because I’m living through a lot of pain. I picked a software to manage my company, mostly inventory & financials: ERPNext. The promises of the software were high, it’s meta data & module oriented, which means that it should be flexible (can be adapted to almost any needs) and composable (like lego blocks). I especially picked it because it’s open source. I value this feature a lot when I chose a software for my needs. But the pain I’m living right now is not related at all to open source, it’s simply related to the maintainers that are user hostiles and or simply careless or negligent. I know how to recognize it, I lived through one of the worst software catastrophes of the past decade, Python 3. I don’t want to go through it again. ERPNext gave me so many pains in the last 5 years but this time I’ve seen enough, I need to speak publicly about this mess.

ERPNext is installed through different methods: provided containers, provided images, step-by-step documentation & last but not the least, an easy install script. 5 years ago I got started with that script, a great helper, like any good software should be, you run it and it does what you expect it to do. The command I ran and documented was sudo python3 install.py --verbose --production --user ubuntu --version 13, it’s pretty straightforward. Only caveats, it will fail the first time, because it needs you to run this command first: export LC_ALL=C.UTF-8. Not too bad. This script described in the documentation did the job without too much hassle. Until about a year ago, I had to reinstall a development environment to debug an issue I had with ERPNext. I much prefer to debug on a development environment than on the production instance. It just failed. I didn’t have the time to investigate the issue so I let some time pass, I told myself, this will be fixed soon. I came back every few months to see if that script was eventually fixed. Today is different, I REALLY couldn’t wait any more.

As you can see in this screenshot, you can see that a lot of people are reporting issues with the easy install script. Not so easy after all… I consider that I can fix any software issues as long as I have access to everything: environment, code & data. Fortunately, this is the case with the easy install script & ERPNext. But it doesn’t mean because that the software is open source that anybody can do what I can. Fixing this bug require deep knowledge about the UNIX operating system, code automation (Ansible), shell scripting, Python & more. An easy script should be easy.

Frappe (the company behind ERPNext) is investing a lot of time writing public relation texts about pay equity, business success stories, letting their employees pick their own pay. You know, looking at their publications they are just perfect. But I’m telling you right there, this is just talk. Because on the action side, right now, I’m telling you they are user hostile. They bait you into open source ideology but keep breaking your stuff. I really tried to love them, at first I was running the software myself but maintaining a service fee with them for the support. I really wanted them to succeed. Then they changed the fees for the service for a pricing model I didn’t agree with. Now they changed back again to the old pricing model. I’m telling you, what they tell you and what they are is different.

As for the fix, it took me a while to figure out the bug. When you try to debug the easy install script, you really want to run it with —verbose command line arguments. Fortunately, I’ve worked with Ansible before, it’s not the first time I’m seeing a wall of text full of stack traces & I know how to grep-fu a codebase. Another tip, when Ansible fail, it gives you a lot of details, for me the most interesting part was inside _raw_param. stderr is telling you what happened but when you want to iterate faster than rerun the whole install script, you copy, paste & run what was inside _raw_param. You could always try to re-run the playbook with the ansible-playbook command but that is a bit trickier since you need to run it with the same arguments and context as the install script.

Mostly, the issue was really just about the python frappe-bench library not being installed by the easy install script. It also seems like the easy install script is removing it but that’s not something I want to find out. I just wanted a working patch for now, I may come back with a cleaner fix in a future.

The fix:

Run the easy install script once, it should fail but it also should create a folder under /tmp/.bench/
Apply the patch below as follows, copy and paste the content in a file named b.patch under /tmp/.bench/

diff --git a/bench/playbooks/roles/bench/tasks/main.yml b/bench/playbooks/roles/bench/tasks/main.yml
index 164a216..3db6b2a 100644
--- a/bench/playbooks/roles/bench/tasks/main.yml
+++ b/bench/playbooks/roles/bench/tasks/main.yml
@@ -35,6 +35,10 @@
     become_user: root
     command: chown {{ frappe_user }} -R {{ user_directory }}

+  - name: pip3 install frappe-bench
+    command: 'pip3 install frappe-bench'
+    become: yes
+
   - name:  python3 bench init for develop
     command: bench init {{ bench_path }} --frappe-path {{ frappe_repo_url }} --frappe-branch {{ frappe_branch }} --python {{ python }}
     args:
diff --git a/bench/playbooks/roles/bench/tasks/setup_bench_production.yml b/bench/playbooks/roles/bench/tasks/setup_bench_production.yml
index b0725da..a85aaa2 100644
--- a/bench/playbooks/roles/bench/tasks/setup_bench_production.yml
+++ b/bench/playbooks/roles/bench/tasks/setup_bench_production.yml
@@ -1,4 +1,9 @@
 ---
+- name: pip3 install frappe-bench
+  command: pip3 install frappe-bench
+  become: yes
+  become_user: root
+
 - name: Setup production
   become: yes
   become_user: root
@@ -21,8 +26,8 @@
   become: yes
   become_user: root

-- name: Restart the bench
-  command: bench restart
+- name: start the bench
+  command: bench start
   args:
     chdir: '{{ bench_path }}'
-...
\ No newline at end of file
+...

Run this command: cd /tmp/.bench/ && git apply b.patch
Run the install script again. For some reason the command bench start never resolve, at least it doesn’t fail like it does with bench restart...

If you are interested to read more about software stability, Kristians Kronis wrote a very long and good text about the subject: never update anything. I also believe we developers can do better with modern tools like Tree-Sitter and start treating code as data to bring better software updates with semantic merges and precision security patches.

I'm currently looking to pair with somebody who would like to work on this meta-data open source resource planning mess to fix. If you like open source, meta programming, stable software and think you can team up with me on this, contact me.


No comments yet

No comments yet. Start a new discussion.

Add Comment