Make OES core services open source and part of SUSE
I know: this is easier said then done. For that, I will not too much go into the patent/lagel/IP stuff that may be involved with this. The question is not that we want this but why we want this. In short, to survive, I believe OES core needs to be open sourced and shipped (branded) as part of SUSE.
I untherstand not everybody (Novell employee's for example) may be happy with such a turn, but I stronly believe it makes sense and would make the (Novell) collaboration portfolio stronger.
background:
Once in the NetWare days eDirectory was king in the directory service world. While eDirectory still has its place in the IDM world, eDirectory as part of OES is just schrinking. Today Active Directory (AD) is king of the Directory Services. Every major vendor supports AD. For this, OES today has it's 'equilivant' Domain Services for Windows (DSfW) which is build on top of eDirectory and Samba. While this works fine for certain use cases, the reality is this is a single vendor solution and a niche product. None of the major vendors supporting AD do support DSfW with their product. Why would they? Few examples are;
-My customers use VMware Horizon View: no support for DSfW. It works, but not offically supported by VMware.
-My customers use Cisco ASA with FirePower and VPN's: Needs AD for user authentication as it has an agent running on the AD Domain Controller notifying the FirePower system on which device the user is logged in. I cannot leverage that feature with OES and DSfW.
-Recently I ran into an issue with a Wireless solution running on an Linux appliance (as an authentication broker) which as an user source leveraged AD. With eDirecrory and DSfW the authentication for Wireless networks stopped after ~2 hours and we needed to reboot DSfW te get that going again. After a lot of troubleshooting with Novell and the vendor, which was very willing to work with us, they still said it 'works with AD'. Then the appliance got a planned support pack and suddenly the authentication issue with DSfW was gone... the appliance had newer Samba modules. So, no DSfW issue at all but a lack of untherstanding/knowledge of the vendor on alternative to AD solutions.
While some vendor solutions do work with DSfW, this does not mean the vendor also does support it. Even if I believe an issue would not be in the DSfW area I do have to convince a vendor support desk the issue at hand is in their solution. Mostly we have to prove this using an AD. This takes and awefull amount of time. The 'advantage' of DSfW is now a disadvantge since there is additional costs involved.
While the open source version of AD is Samba, even that is not supported with AD requiring solutions.
Collaboration Portfolio:
Novell has a bunch of products that depend on each other as they do share code; OES, Filr, Vibe, iPrint. As I do not want to touch all aspects, in short what I do see comes down to this: as the install base of OES does shrink, this means less resources to develop OES and that impacts depending solutions. For example SLE12SP1 is available today but OES on SLE12 is still on the 'radar'. That means appliances for products sharing OES code can also not ship SLE12 yet. Then all the effort needed to move OES to SLE12 means also less features that can be added in that timeframe. The OES team spends a lot of time to keep OES running on the platform.
What is OES:
So, if I take a look of 'what makes up OES today' this would be 'an alternative to AD'. Simple said 'Samba with and eDirectory backend' (instead of database) for user/device authentication and storing files. The future of OES is DSfW with SMB access to volumes. NCP will go away as there is just no place for that anymore. The customer's DSfW targets are enterprises. But those enterprise also run Cisco, VMware and other solutions. So, even as it targets enterprises, provide enterprise support on an (open) platform (SLE) this is not enough to convince 3th party vendors to support this solution. And if it is not supported, why would my customers invest in OES?
Market of two big vendors (reasoning):
Most markets have two big vendors and a bunch of smaller ones;
-Windows vs OSX (desktop)
-Windows vs Linux (server)
-Android vs IOS (mobile)
-Citrix XEN desktop vs VMware View
Well, you get the point. In the directory services perspective there is pretty much only AD at this point. All mentioned solutions do work/integrate with that at some level. Even the solutions leveraging a lot of open (source) components do. That makes me wonder why not fe Samba. Only thing I thing I can come up with as a reason is that is not enterprise scalable. Maybe even seen as a risk due to reverse enginearing effords? I've not really looked into this but at least it seems not to be interesting enough (not enough demand?) for the Cisco's and VMware's of this world.
This makes me believe there would be room for a second Directory Service that is open AND enterprise supported. This versus a closed and single vendor solution such as AD.
Note: As Active Direcory is tied to Windows (today) it would be a matter of time before Microsoft decides to port this to Linux. Today they 'love' Linux. That would IMO mean the end of eDirectory on OES as why would we develop DSfW if there is AD on Linux already. For IDM eDirectory would still be supported of course, becoming a nice soluttions. Also Samba would be hurt by an open source AD. Question of course is what license would Microsoft tie to such a solution. IMHO they would take such a step to disturb the Linux market and tie everybode more into AD.
Why would open sourcing OES (core) be a good idea?
They way the marked evolves and the way OES's connected to other Novell solutions does. The OES core components of interest such as eDirectory, SMB services, DNS, DHCP, etc should be opened up and made part of SUSE as they have a much better fit there. This would mean:
-SUSE can ship those components as part of SLE, LEAP and openSUSE. This will give those 'enterprise ready' and 'enterprise supported' components to a much bigger user group. They can take advantage, learn and use it with support of SUSE.
-leveraging the SUSE Build Server those components can be build for other platforms (RHEL, Debian, etc). This would mean OES is no longer a nich product. We can say it runs on any platform, so no vendor lock-in as with AD. That may appeal to the Cisco's and VMware's of this world to adopt it a the AD competitor. In the case of VMware, which today uses SLE for it's Vitual Center appliance, this may be a way to deploy VM's in a DC much 'cheaper' compared to leveraging MS AD. I'm thinking of a 'Directory Services in a box' solution which only need one to make a one/two way thust with to get your solution going (appliance).
-As SUSE provides core components Novell (Micro Focus collaboration team) can now build on recent SLE solutions for Vibe, Filr, iPrint and OES (what's left of that if not all moved into SUSE). That means MORE focus on the solution and LESS on the platform.
-NetIQ (Micro Focus security team) can still build on an open eDirectory solution. This is 'just a database' as the real value is in the IDM and Security solutions on top of that. Also here the advantage of SUSE Studio to build eDirectory on more platforms.
-If not all of OES is opened up and moved into SUSE, a Micro Focus braned OES could still add like NSS (for AD), add clustering to the mix and additional enterprise support on to of the SUSE support. IMHO I would create just a more tied integrated collaboration solution as today's solutions lack integration. MF OES could for example integrate Storage Manager and such to complete the solution. The focus must be on a real enterprise expirience.
-What's in for SUSE: OES core would add a really cool enterprise component to the solution stack which no other vendor has today (on Linux).
by: Sebastiaan V. | over a year ago | DSFW
Comments
I just remember the NSS filesystem was open sourced a while ago
https://wiki.microfocus.com/index.php/File_System_Primer