A recent presentation just reminded me of “The Zen of Python.” It’s a collection of 20 (19?) software principles, particularly as they relate to the Python programming language.
Since OSS is software-defined, (almost) all of the principles (not sure about the “Dutch” one) relate to OSS in a programming sense, but perhaps in a broader sense as well. I’d like to share two pairings:
Errors should never pass silently.
Unless explicitly silenced.
Unfortunately too many do pass silently, particularly across “best-of-breed” OSS stacks.
And
Now is better than never.
Although never is often better than right now.
An especially good hint if you’re working within an Agile model!
So that got me thinking (yes, scary, I know!). What would a Zen of OSS look like? I’d be delighted to accept your suggestions. Does one already exist (and no, I’m not referring to the vendor, Zenoss)?
In the meantime, I’ll have to prepare a list I think. However, you can be almost assured that the first principle on the Zen of OSS will be:
Just because you can, doesn’t mean you should.
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
