OpenPaaS’ Newsletter — November 2018
Around building software
Beware readers: this newsletter is about the context around building a software and wasn’t written by a developer. Don’t run away yet, as it has however been signed off by a handful of them.
Good reading!
Planning before writing
Building a complex software is a long endeavor, which (arguably) starts long before you even start to write your first line of code. Prior to typing on your keyboard, a handful of critical decisions much be made that will have long lasting effects on the life of your project:
- Programming language to use (i.e.: JavaScript; Java; Go; Rust; Swift; Kotlin; etc.);
- Components and libraries to rely on (i.e.: MongoDB or Cassandra; RabbitMQ or Apache Kafka; VueJS or React; etc.)
- Functionalities to implement (i.e.: what your software will do and perhaps more importantly, won’t do)
- The architecture of your software (i.e.: how to model your software’s internal structure)
- The right level of abstraction for your infrastructure (i.e.: from bare-metal to serverless architecture)
- Platforms to target (i.e.: Android; iOS; Windows; macOS; web)
- Development method to use (i.e.: Agile Scrum; Kanban; etc.);
- Target market (i.e.: B2B; B2C; the entire universe and beyond)
- Business model to follow (i.e.: an open source core with proprietary and paid functionalities built on top of it; a fully open source with paid services such as integration and support: the latter is what LINAGORA is pursuing)
- Licensing scheme to choose (i.e.: permissive open source licenses such as the MIT or Apache License, or less permissive ones such as Affero General Public License, which OpenPaaS uses)
- and so forth.
This list is not ordered. Jonathan, from the newly created LinShare SaaS, would put it in this order:
What? What kind of service do I want to offer? With whom do I want to work? (a method is needed if more than one person is involved)? For who? Just for me, to sale it, or to offer it to the community? How? First: design the architecture, then pick the language, the database and at the end the libraries.
Each decision implies trade-offs. For instance, if you write system-level programs, you might want to pick a really recent programming such as Rust, which is considered to be safer than other alternatives, but if you do so, it will come at the cost of having lesser developed libraries (which is arguably balanced by the fact that Rust libraries are known to be of high quality. I am looking at you npm).
For this short article, we will focus on three elements only: the model, the tooling, the programming language and its libraries, from a developer’s perspective.
The model
Just like architects, developers are using a variety of tools to build complex artifacts. But unlike architects, developers’ tools are rapidly evolving.
A striking difference between software engineering and pretty much any other industries is the fact that developers are allowed if not encouraged to reuse a tremendous amount of existing components to build their project faster, thanks most notably to Open Source software.
OpenPaaS, which was released earlier this year, is built on top of many Open Source components, and, perhaps, would not exist if those elements were not widely available and free to use. At the very least, we acknowledge the use of those components, such as MongoDB, RabbitMQ, or James, and whenever we can, we contribute back. In the case of James, we even lead the development of the component being used.
The open source model allows to reduce the number of components you would need to normally have to build yourself, and to reduce the maintenance burden. It can greatly accelerate the pace of your development. It comes at the cost, tough: you rely on the work of others, and as it the case of MongoDB, you may not appreciate where they are heading too, from a technical or a legal standpoint.
LINAGORA’s software such as LinShare — which we dedicated our newsletter to last month — and OpenPaaS, are both embracing the open source model, without any proprietary features built on top of it. We call it the free-free model.
The tooling
At LINAGORA, we use GitLab to host our code repositories. Just about two years ago, we were relying on Atlassian Stash, now known as BitBucket. Nowadays, on top of hosting our repositories, GitLab is also used to do issue tracking and to implement continuous integration, something that was done by individual tools before. On top of that, GitLab allows code to be reviewed, which is an important part of a developer’s job. According to Ayman, which is primarily working on the calendar part of OpenPaaS, this consolidation has been beneficial:
No need to swap between three applications anymore. Everything is available in one yet powerful application.
Bonus point, our internal development teams are using GitLab in creative ways, such as by relying heavenly on Mermaid to draw diagrams and flowcharts.
Language and libraries
More than five years ago, the foundations on top of which OpenPaaS was about to be built were laid.
OpenPaaS, our open collaborative platform, is mainly written in JavaScript, the language of choice for developing dynamic web applications. JavaScript is more than a language, it is an entire ecosystem, and OpenPaaS is heavily relying on it, since the beginning as a research project to nowadays, as a system running in production.
A few words on JavaScript. At the beginning of its journey as a programming language, JavaScript was meant to only run code on the client, directly within internet browsers. But popular projects such as Node.js came to life, to allow JavaScript to control what would happen on the server side.
Node.js has its own package manager, called npm, which allows developers to look for useful components they could reuse to build their applications upon.
What about the front-end? In the case of OpenPaaS, which relies on AngularJS in its first iteration, we recently had to make a choice for a new framework: we ended picking VueJS, against React as the main contender.
Consider the present article to be a teaser, as in a not-so distant future, our reasoning behind this choice may be laid down on a technical article.
In the meantime, we may want to have a look at past articles on AngularJS and its dynamic directives, as it used by OpenPaaS.
Conclusion
That’s about it! We hope you have enjoyed reading this newsletter!
Keep in touch with OpenPaaS on Twitter, Facebook, GitHub, and our dedicated Forum. For LinShare, follow its Twitter account.
Interested in joining LINAGORA? We are hiring!
