In this article, we look behind the scenes to understand how the team at /e/OS works!
For those who have not been following up on the developments in the smartphone OS world, /e/ OS is a de-googled, privacy-focused, android-based smartphone operating system. The project is the brain child of Gaël Duval, the man who created Mandrake Linux. /e/OS is forked from LineageOS.
The team did not just stop with the forking. First, they removed the Google calls which were spread all over the source code. Next, they replaced several of the default apps and added FOSS replacements. With a single /e/ account, user data on the phone could be automatically synchronized with ecloud servers. What data was to be synced can be controlled by the user.
By the middle of 2018, the beta version of the /e/OS was ready. /e/OS today supports 91 smartphones. For those who are not comfortable flashing their smartphones, /e/ offers a range of refurbished smartphones, which can be purchased with /e/OS already flashed on them. Currently they are testing Mail-in-your-phone, a service where users who are not confident flashing their own devices, can send it to /e/ and get it flashed!
All this forking, debugging, rewriting and modification requires design, development and testing efforts. After the OS is flashed on smartphones, support for the end users is required.
Lets understand how /e/ manages all these different activities.
Remote Working
Traditionally, all organizations worked from brick and mortar structures. IT companies were no different. At the start of the day, employees would jump on to private or public transportation and rush to their office. There the work-force, confined behind endless rows of desks would slog for the next couple of hours
At the end of the day, dusty and tired, they would make the same tedious journey back home. Weekends and public holidays were eagerly awaited. This was the only time the ‘workers’ got to spend with their friends and family members. The situation has not changed much over the years.
With the advent of high speed internet and computers, the concept of remote working came into being. Workers in certain sectors , especially in the IT industry can now afford to ‘work from home’.
Working Remotely means
- no traveling
- flexible work hours and
- working from an environment you are comfortable with — like your home!
Having said that like every other idea or concept ‘Remote Working’ has its pro’s and con’s.
Lets look at how the process works for /e/ and its team members.
At /e/OS, everyone works remotely.
Team /e/ has developers, managers, testers and support team members like any regular IT organization. These employees, volunteers and team members are spread across countries. They come from Brazil, Europe, India and go all the way down-under to Australia and New Zealand.
That being said the team still manages to meet its deadline, set targets and achieve milestones.
Lets take a closer look at each link in this chain and see how it works.
Project Management
The project or to be more precise, the open source code is managed on /e/’s dedicated Gitlab instance. Gitlab, the tool for managing project life cycle works through a web UI. It fits in perfectly with /e/’s philosophy by being Open Source. On Gitlab it is not just one single /e/OS project. There are multiple default apps and associated services which run in the background to make the user experience smooth on the OS. These apps and services in the form of projects and source code reside on gitlab.
One of the key features is Continuous Integration (CI). The gitlab instance can trigger /e/OS builds automatically or manually. As mentioned previously /e/ supports 91 smartphone devices as on date of writing . The builds for these devices are delivered to the users over-the -air (OTA) . In addition there are builds made for testing code. On an average, the build time could be anywhere from 1–2 hours. The build activity is shared by ten powerful servers. Gitlab handles the load balancing between the servers and make the build process work smoothly and seamlessly.
/e/ Projects on Gitlab have two levels of access:
Internal
- Accessible only to development team members,
- Used for storing internal documentation
External
- Code once tested is moved to the section of Gitlab and is accessible to all including users
- Users can access the source code and download it in case they want to build the ROM from these branches
- Users can track the changes and monitor development progress
- Developers do their fixes on git branches. Once they confirm that the code is working as expected it is checked into the main branch
The /e/ development now follows the agile methodology where sprints define a development cycle.
- A set of bugs are identified and assigned as part of a sprint cycle.
- Next the development team members are assigned the defects.
This is how the development — testing cycles time-lines are distributed
- Development & defect fixing : 2 weeks
- Testing : 1 week
In case any defects get detected during the testing cycle those specific changes are pulled back from the release.
- If these defects can be fixed in the same cycle of testing they are fixed and a new build is released for testing.
- In case the defects at more serious and cannot be patched into the same sprint they are move to the next sprint cycle.
To give the sprints a more ‘humane’ touch, they are now named after cities from around the world. The team has completed Alexandria, Beijing , Cordoba, Delhi, Edinburgh and Freetown sprints. Next they move on to Guadalajara and Hobart !!!
You can get more details on these sprints on Gitlab or read what fixes and improvements went into each of the sprints on the forum.
The Development process is available for the development team members on /e/’s internal wiki. The process gets upgraded based on the feedback received from the team members.
Issue Management
Here again we have Gitlab which allows users to raise issues and track progress on their resolution. Romain, as the Project Manager has set clear development guidelines which the team members follow .
These guidelines are available in Gitlab through a developer access. For example, this is a screen-shot of some of the processes defined for raising an issue, assigning and working on the fix for it.
As you can see in the menu list on the right there are guidelines for every conceivable process area defined. The team is open to suggestions and based on suggestions changes and improvements are made to existing processes.
The /e/ OS users also get to play a role in the raising of defects.Access to Gitlab is available through a Gitlab ID which a user can create here.
Lets have a look at the statistics of the defects in Gitlab at the time of writing
Not bad for a team of 20 developers working on a total of 91 devices over two years !!!
Support Activities
One of the key components in the success of any project is its user base. At /e/OS a lot of the success achieved so far has been dependent on the support of its user base. A team of volunteers from across the globe help with the support activities for the /e/OS .
Support or assistance in understanding and usage of /e/OS is available through these modes:
- /e/ Wiki Documentation
- Community Forum
- Telegram Channel
The Community Forum which started in October of 2018 has about three thousand users at present. The forum gets about 5000 user views on an average day. The forum is also the place where users raise their issues and discuss points of common interest and concern. Besides English the forum provides support in French, Spanish, German and Dutch.
There are multiple telegram channels which help with the support activity. Here again it is the users who help resolve issues that are raised by other /e/ users. There is a public channel for general discussion where users can join on request.
The support team volunteers and users on the forum and channel provide solutions and help out where ever they can. Issues where developer assistance is required are raised as bugs on Gitlab and get fixed as a part of the sprints based on the issue priority.
Testing
The key to a great product is multiple layers of testing. The /e/ development team does the first level of testing. A team of volunteer testers formed from the user base does the second round of testing. The test builds are available over the air (OTA) for the testing team.
- /e/ Builds that go out to user devices get a ‘dev’ build tag
- /e/ Builds that go out on the Refurbished devices that /e/ sells, get a ‘stable’ build tag.
The difference between the two being the stable builds get a third round of testing on the devices before being sent out OTA.
The team now plans to add an additional layer of automated testing to the process.
This would further enhance the stability and reliability of the OS.
Communication
Communications in a team is one of the most important factors and can make or break a project. At /e/ the team uses Telegram and emails to communicate. All team members are usually available through out the day and occasionally on weekends on the developer channels.
Now lets looks at the pro’s and cons in ‘Remote Working’
PROS
- Ability to attract talent from across the globe
- Employees able to balance their work and family life better
- Improves productivity as there is no time wasted in traveling to and from office
- Cost effective — no need to maintain brick and mortar offices
CONS
- Little or no inter personal relationship as team members hardly meet each other physically
- Co ordination can be an issue at times
- Delay in getting ideas across due to employees being in different time zones
- Language barriers — messages sent through Telegram or emails do not exactly have the same effect as spoken words
How T/e/am manages to overcome these issues
In any team no matter how perfectly organized there would be issues. That is the fundamental nature of human beings. We have our own ideas and never hesitate to express them. At /e/ the development team is no different.
The way we have handled this at /e/ is by creating a vibrant work culture. Every member in the development team is free to express his or her opinion about topics that concern the OS . This is true even when the issue is related to modules or Apps they themselves are not developing.
Team members express their opinion frankly on the developer channel. The topic is debated and everyone’s opinion is heard. Decisions are arrived at based on
- Technical feasibility and
- User and team consensus
Finally the change request is added as a bug to the Gitlab and taken up as part of the development plan.
It is not only development activities that get discussed on the telegram channel. Recently a request for /e/ t- shirts was made by development team members. Within a month the t-shirts were shipped out from Europe to all corners of the globe !!
Summary
To summarize /e/OS is still in its initial stages of development. As the great poet Robert Frost said, ‘ But I have promises to keep and miles to go before I sleep and miles to go before I sleep….’ That is true for /e/ as well. We started with a promise from Gaël to free smartphones from the duopoly of Google and Apple. We are still a long way from that goal.
Team /e/ is confident that with a common purpose, shared vision and a laser sharp focus, the team will be able to achieve their objectives and build a safer, better world for fellow smartphone users across the globe.
