hpr-knowledge-base/hpr_transcripts/hpr1255.txt

Episode: 1255
Title: HPR1255: A life in a software project
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1255/hpr1255.mp3
Transcribed: 2025-10-17 22:30:37

---

Hi, my name is Garjola and you are listening to a contribution to Hacker Public Radio.
In this episode I will read something for you.
A friend of mine wrote a blog post the day of his 40th birthday.
The title was version 4.0 is out.
I found it very interesting as he told the story of his life as if it was a software project
with a major x.0 release every 10th birthday.
So here we go.
The new version of the software is out.
With this new stable release many new features are available, but the main news is the complete
refactoring of the core of the system.
Indeed, after the discovery of the backdoor inversion 3, a complete revamping of the system
was needed.
As a result, a much cleaner and efficient code has been produced, free from memory leaks,
dead logs and raised conditions.
The project team would like to thank all the beta testers who have been kindly helping
in tracking bugs and even in proposing clever fixes.
I would like to take this opportunity to go back into the history of the project.
Let me tell you a little story.
Version 0
This was an aid implementation and a rather incomplete code base.
The API was of course very limited in scope, but users found it very friendly and easy
to work with.
It was written in Python, so everybody, even with nearly no experience, could understand
the code.
The license was public domain, yes, as an aid as the code.
Version 1
This was a very good release of the system which combined, breath, in scope, many new features
were incorporated, but also a very efficient implementation of the major parts of the
software.
A progressive translation from Python to C++ was done, but no object orientation was used.
It was C written in C++, plus some simple use of templates.
The license moved from public domain to a BSD, mainly to gain popularity among users,
and the goal was reached.
These were good times for the project.
Version 2
We have mixed feelings about this version.
It started as a follow-on on the 1.x series.
Up until version 2.4, new features were added, not many of them, but some useful.
As for instance, the internationalization support.
In terms of paradigms, a move was operated towards object orientation.
Again, up to version 2.4, same choices were made, but after that the OOP hip took over,
but temptations towards multiple inheritance were avoided.
In terms of licensing, an open core approach was adopted.
The core of the system remained open-source, but the added features started to become
closed-source, following the advice of the marketing team.
Version 3
These were hard times which nearly led the project to stop.
Indeed, the marketing team was forcing the engineers to follow a dangerous path.
This is what usually happens when there are no real goals and when people with no technical
background and only money in mind make the rules.
The team's hacker spirit was lost and a general lack of motivation could be felt among
the most creative ones.
OOP was officially adopted, but not everything was negative about that.
Indeed, there were two very important features added, which would have never existed without
OOP.
The technical team admitted the responsibility for delaying them too much, and we'll always
thank the marketing team for pushing these features.
However, the marketing guys didn't understand that one should stick to base principles,
nor they did understand that limiting the scope of the features is sometimes needed in
order to ensure quality and a high degree of coverage.
The engineers were forced to use technologies which were not suited, but which were pushed
by buzzwords.
Much time was spent on unneeded retrospectives.
Many different languages and technologies were mixed up, Java, Ruby, PHP, to name only
a few.
And the hackers lost focus.
The headquarters were moved to a new building which was too expensive and much energy was
spent on this.
When your release had to be pushed out every few months, but only the marketing team decided
what the release dates were, as well as the feature sets.
This was rather extreme, but not really agile.
Last but not least, the license changed.
After a couple of minor versions where a license contributor agreement was imposed on all
the developers, the whole code base was licensed under a closed license.
Many seemed to be the only goal for the company.
Version 4
Severe stability issues were detected in the system several months before 4.0 was due.
The marketing team issued a press release which stated that the technical project manager
was held responsible for many bad choices and that he had been fired.
An independent audit of the code was made.
Here's from the community of former contributors offered their help, which resulted to be crucial.
Indeed, a backdoor in the system was discovered and the committee logs showed that a recently
hired programmer was responsible for that.
It was then discovered that he had been following orders from the marketing team who had other
plans for the software and wanted to replace the technical team.
The community decided to fork the project, but they had to start from a version previous
to 3.0 because of licensing issues.
Actually, these had many advantages and the price to pay, loss of a few features, was worth
it.
The main advantage of going back some versions was starting from a code base which was
not bloated, even if the 3.x series was a bad one, many experience was gained mainly
about what has to be avoided, buzzwords, shiny gris, etc.
The hacker's spirit was back.
The programmers were again happy to code.
They were at last free to choose approaches and paradigms.
For instance, the use of a functional language for writing extensions was adopted.
This allowed them to keep the core of the system written using efficiency plus plus and at the
same time use per functional approaches when needed.
Only one thing from 3.x was kept, the good parts of OOP and inheritance that written
in a list dialect, not in Java or Ruby.
As a commitment to the users, the new gplv3 was adopted so the system could never be closed
again.
That's a conclusion.
The hackers are back in business and have many ideas to keep improving the system.
The user experience, mainly for users, alpha and beta is one of the main focal points
of the team.
Stay free, stay open and don't forget to hug your world, happy birthday!
So that's what my friend wrote.
Now I will give you some information about him.
His wife left him several months prior to this 40th birthday.
She left him from somebody else who happened to be a programmer working on a software project.
My friend's ex works in the sales department of the same company.
If you listen now again to work my friend wrote, you may understand different things.
Okay, that's going to do it for this episode.
If you want to send me any feedback, you can get in touch with me by email at garjola.net.
Garjola is spelled G-A-R-J-O-L-A.
Thanks for listening and thanks to Hacker Public Radio for giving every hacker the chance
to become a podcaster.
Talk to you again soon.
Bye bye.
Hacker Public Radio is founded by the digital dot-pound and the infonomicom computer cloud.
HPR is funded by the binary revolution at binref.com or binref projects are crowd-responsive
by lunar pages.
From shared hosting to custom private clouds, go to lunar pages.com for all your hosting
needs.
Unless otherwise stasis, today's show is released under a creative comments, attribution,
share a like, feed us our own license.