“John D. Rockefeller wanted to dominate oil, but Microsoft wants it all, you name it: cable, media, banking, car dealerships.”
Ralph Nader.
As a friend of mine often says, “the two most commonly used OSS tools are Microsoft Excel 2007 and 2010.”
Whether it’s design packs, address management, joint/splice schedules, asset lists, etc, etc, etc, spreadsheet tools are used within OSS workflows in almost every company I’ve worked with. I’ve even seen some CSPs use spreadsheets in lieu of buying an OSS.
It makes sense in many ways. Spreadsheets tend to be intuitive, commonly used and are infinitely flexible. The downsides mainly relate to maintainability and scaling. The other downside is that the data being created and consumed within the spreadsheets aren’t embedded within the OSS database (unless you perform a data load, which is easy enough, but a bit of a pain if you’re regularly updating your spreadsheets).
I wonder whether it actually makes sense for vendors to offer a simple, spreadsheet-like tool as part of their OSS-suite that allows operators to quickly and easily store free-form data directly in the OSS database?
It would be ideal for ad-hoc queries (free-form data is immediately cross-referenceable with other data in the OSS database), storing all sorts of ad-hoc lists/matrices of information in a single place, augmentation of core OSS data sets for specific customer needs, custom apps can be developed from a single OSS database, ensuring free-form data is dependable as a result of OSS high availability mechanisms and I’m sure you can think of many other reasons.
It sounds too simple. I must be overlooking something silly and obvious… Please help me out here. Are there reasons why a vendor wouldn’t want to do this?