Joe Stanganelli 10/13/2017 | 10:26:07 AM
Inevitabilities of commercial standards This has all been inevitable.

Open source and open standards catch on -- for good reason.

"Big-Corp" entities become increasingly criticized and ostracized because of their proprietary, competing, non-standardized natures.

So these major companies and carriers start joining open-source and open-standards movements -- for multifold gains. PR value. Learning from other developers. And, of course, helping to contribute to open source and open standards.

And not just contributing. Leading. Shaping. The optimistic apologist says that it's a matter of QC. The cynic says that it's about gaining back some of that dependency. The realist says it's probably a bit of both.

And now these competing standards are even more heavily competing with each other -- to the point that major carriers and other big enterprises are withholding their support/membership from certain open-source/open-standards organizations in the face of heavy involvement of rivals in said organizations.

As things begin to decentralize more, I suspect this will eventually come full circle.
Gabriel Brown 10/15/2017 | 10:04:47 AM
Tribalism & Competition To some extent, competition and conflict is a necessary part of any industry, fueling innovation and improvement in product design and processes. 

You need competition. If it's all design-by-committee you know what you end up with. To extend your theme, is a "European Commission of telecom" really what the industry needs?
brooks7 10/16/2017 | 10:09:30 AM
Re: Tribalism & Competition @Gabriel,

The industry sort of needs such an entity but only for specific things.  The ITU, IETF and the 802 committee are such entities.  Note that they focus on Interfaces and Interconnection of things not implementation.

I think this notion that products need to have consistent internal implementation is a completely flawed notion.  It is eliminate the ability to have a fast moving and creative industry and did not happen on the IT version of this process.  Take a look at the LAMP stack.  That is about as plug standard as things get, but there is no set of requirements for it.  Nobody has to use it.

To me a better approach is to pick products and make something.  To sit in a large room with a bunch of people will get nowhere fast.  No matter what you choose there will be problems with it.  You can then contribute code to overcome those challenges and get them in the baseline of the next version.  All of this will come from real world implementations, not from some set of people sitting in a room.




Carol Wilson 10/16/2017 | 10:51:02 AM
Re: Tribalism & Competition I totally agree that interfaces and interconnection are the primary points at which agreement is needed but, to Iain's point, if you have multiple groups defining these and developing them, is there ever really concurrence on what they are?

A lot of the folks I interview say TMForum work is foundational, and MEF is building on that and trying to coordinate with ONAP as well. That looks like progress on that one front. 

But on the edge computing side, as Iain rightly notes, the efforts are still very scattered. 

To this point, the push to products has been accomplished by a network operator choosing a team of vendors - with one vendor providing the ecosystem backbone or orchestration - and moving forward on specific goals, or a massive network operator like AT&T developing its own massive software platform. 

The approach you suggest makes sense to me in its practicality - pick products and make something is moving forward, and in this alleged era of "fail fast," movement forward is better than being stymied by interminable discussion. 
Joe Stanganelli 10/24/2017 | 2:22:01 PM
Re: Tribalism & Competition Point well taken. But Europeans seem to love meetings and bureaucracy even more than we Yanks do. Expect plenty of commissions and committees and subcommittees and more.
Joe Stanganelli 10/24/2017 | 2:25:44 PM
Re: Tribalism & Competition @brooks7: A Verizon exec I recently spoke with echoed your sentiments. When it comes to building real cohesion around standards in a useful way, he argued, interface work is important -- but involvement in real-world implementation and the how of getting things done internally just gets in everybody's way.