Keep it simple

Developers like open source when the solution makes their life easier. They turn away if it’s more complex than their daily challenges.

Also the maintainer of an open source community project is in need to avoid complexity.

Because simplicity will lead into a manageable environment:

  • Easy to keep documentation on track
  • Less efforts on providing updates and upgrades
  • Less risk to lose sight of vulnerabilities on code reviews
  • Clear legal fundament with transparent license policies

If we look on FIWARE to today, the eco system needs improvements to attract developers and to provide a maintainable eco system.

Keep is simple will be good guideline go into a reliable future.

But it also takes some painful actions:

  • Remove all parts from FIWARE which are not useful for the core solution (btw. What’s the core solution? Internet of Things, Smart Cities, Rich Media or 3D User Interfaces? State today it sounds like a solution for everything – which is not helpful to attract developers)
  • Reduce Code to a common Open Source License model (instead mixing at least 9 different licenses under one core)
  • Bring the GE’s to common Linux based distribution (force maintainer to adept on a common distribution base)
  • Rebuild the documentation (it will be less documentation than today, more easier to maintain)

It sounds easy, but avoiding complexity on an open source eco system is a never-ending task. State today this is not a question of money. It’s a question of willing ness of courageous actions.

hello world!

Learning a new programing language printing „hello world!“ on you screen is the first step of success. It’s a very good analogy on our first milestone with the FIWARE Association.

In the last weeks we build up a board of exiting people to get faces on the front of the FIWARE Association. From now the FIWARE Association has a visible frontend and we move into the phase of action.

hello worldOne task will be building bottom up a sustainable open source community for the further development of FIWARE. Developers should contribute their reviews of the FIWARE stack and improvements of Generic Enablers to maintainers. That’s minor a question of open source code management tools – this is more over a question of creating and keeping open source spirit in the FIWARE community. “Let’s inspire” will be a good driver for the FIWARE association. 

FIWARE has the potential to become an open Gateway from BAN (Body Area Network build with wearable) to VWAN (Very wide area Networks on meshed Smart Cities). The FIWARE stack needs to run on a common Linux base upon different scales: from an e.g. Arduino in the IoT up to a VM  or a massive Cloud Service.

The vision: "FIWARE out of the box" – simple to install and easy to integrate on every scale.

To achieve this we have to get rid of dependencies in the actual GE Stack: License mismatch and unmaintainable code.  This will open a wide ecosystem for FIWARE and a big business potential for everyone: Enterprises and SME as well.

Mirko Ross

Shift the Gateways in public hands

As we can see pragmatically IoT as a ‘seamless’ link (or attempt at a kind of ‘seamless’) link between the BAN (Body Area Network), LAN (Local Area Network), WAN (Very Wide Area Network and VWAN (Very Wide Area Network), or body, home, car and city or wearables, smart home, connected car and smart city, we have broken it down in these four groups in and through which we will group components and enablers.

Just look at what Google is doing; two ways into each network: Glass and Lens, Power meter and NEST, car and in automotive alliances and media system, google.org for open data initiatives and  projects in virtually all public libraries. It is clear that the products are not simply products but gateways and hubs. Endusers will pay for and to whoever links up these gateways in one coherent offering on health, home convenience and security, mobility and the set of services that the city has become.

We believe that these gateways should be in public hands. As the gateways are products we should build these with public and open source enablers.

Rob van Kranenburg

1 2