Tag: startups

The importance of preparation

March 6, 2022 /

I started wondering how people can prepare themselves for such times, given the recent events. Military clashes are happening in the real world and the cyber one in modern times. The are many parallels between defending assets in both of these worlds. In this article, I shall try listing the different approaches one could use to harden their defenses. At the same time, I shall try giving a clear picture of the target goals of the defenders. 

So what is the ultimate goal of every defender? By default, it is to make the cost of the attack too high, and this way to diminish the gains of that attack. This kind of narrative is often seen in many books focused on the defensive side of cybersecurity. It is important to note that sometimes, people attack other people for personal reasons or even because of emotion. In these cases, attackers usually do not care how much it will cost them to perform the attack. As a defender, we should consider these reasons during the design phase of our defense.

You can see a sample architecture of an off-grid data center on the diagram. Such data centers have much better resilience during any events

There is one exciting proverb regarding the importance of preparation – more sweat in training, less blood in the fight. If we transfer this to the realm of cyber security – the more efforts we put into preparing the infrastructure, the less likely it is to be penetrated. So how we can prepare ourselves for an attack:

  • Buy quality equipment: Your equipment shouldn’t be the most expensive or cheapest. You need gear that can do the job and have a lifespan of at least five years. It is a good idea to buy multiple pieces, so you have hot swaps in case of failure. Items in the middle price range usually are good candidates. 
  • Plan and train: There is little sense in having great gear without using it. Regular training sharpens the skills and decreases the reaction time during the use of the equipment. At the same time, testing the items help check their limits and allows the designer to prepare a better defense. In the realm of cybersecurity, we could do regular red/blue team games where the red team will try to penetrate the infrastructure, and the blue team will defend it.
  • Be realistic: If your attacker has much more resources (money and time) than you, they will penetrate you. There is no great sense in making sure your electronic infrastructure survives an EMP wave coming after a detonation of a nuclear warhead. At the same time, it makes excellent sense to make sure your data is backed up into a protected vault and that you have replacement units if such an event happens.
  • Hack and Slash: Don’t be afraid to modify your equipment if it does not suit your needs. Many security units prefer buying cheaper equipment and rigging it for double or triple purposes. Play around with your gear, and don’t be afraid of breaking it. Sometimes you can find real gems by doing that.

In conclusion, preparation for any defense activity comes with a lot of research. The primary goal of every defender is to increase the cost of attack. The higher the price is, the less motivated the attacker will be. Often the resources of both sides are asymmetric, and thus, some defenders must think such as guerilla fighters or even as Start-Up owners. They have to squeeze the last piece of efficiency provided by their infrastructure.

The minimalistic Start-Up – Structure of the team

February 12, 2022 /

These days, many articles explain how people must have a side hustle and create multiple income sources. Unfortunately, one significant disadvantage of this media is that it does not successfully demonstrate how to build such a side hustle. It does not list the disadvantages and sacrifices coming with having such. And finally, it does not explain how to create a team working on that side hustle. This part will address these challenges and describe how our hypothetical team can resolve them.

But let’s start with listing the main disadvantages of having a side hustle:

  • Time-consuming – If the team wants to have a successful spell working on the hustle, each member must allocate a minimum of ten hours per week. Suppose you try combining it with having a family. In that case, things could become quite hairy because people start balancing between their family and their side hustle, which often leads to disaster.
  • Distraction – Having a side hustle could affect people’s primary income source because they spend the dedicated weekly amount of time working instead of resting. Such a way of work requires motivation and internal drive in the long term.
  • Could be expensive – By default, the main expenditure for every Start-Up is its marketing. And to generate an income, every company needs marketing. It does not matter whether it is a fully-fledged organization or just a side hustle. Without marketing, there is no money coming. And yeah, marketing could be costly.
  • Not perceived as serious – One of the main problems with side hustles is that customers do not perceive them as a serious endeavor. And unfortunately, such prejudice is often correct – nowadays, customers expect organizations to have excellent support in addition to the products and services offered. Dedicating around ten hours per week for the side hustle is usually not enough to cover all the product development aspects and product support. 
You can see a standard dropshipping side hustle on the diagram, where the team “just creates” a website and starts earning money. The main problem is step one – how do you ensure that the routed “traffic” will start buying your products

After listing all the most critical disadvantages, let’s see how our hypothetical team can overcome them. The mandatory requirement for a moderately successful side hustle is to have at least ten hours per team member per week. In real life, if one of the team members can not dedicate such an amount of time per week, the setup becomes fragile, and there is a high chance of disaster. Having this prerequisite fulfilled, our fictional group could use the following mechanisms to improve their efficiency:

  • Meetings every two weeks – The standard agile workflow dictates having synchronization meetings at least twice per week. However, in our situation, the amount of time dedicated per week is four times less, which logically dictates that having four times fewer meetings will keep the team in good shape and, at the same time, will keep the work tempo high.
  • Have a single decision-maker – With teams of less than seven people (the maximum number of people participating in a side hustle), the most efficient team structure is flat. Such form speeds up dramatically the decision-making process and makes sure that the team is not stuck in endless discussions and arguments.
  • Make the expectations clear – With so few hours per week, there is no space for flexibility. From the beginning to the end, the team must know their priorities and what they could expect from this side hustle. Any change in these priorities will lead to a lack of focus and decreased level of motivation.
  • Have fun – Too many people take too seriously their side hustles. They genuinely believe that they could scale their hustle to a multi-billion company with many employees and branch offices. Unfortunately, in reality, the main advantage of doing a side hustle is learning new skills and investing your time in something meaningful. Earning money for 99% of these endeavors is a chimera, especially if the team members do not have the proper background and experience in starting up new products or companies.

We shall have three back-end devs, one front-end/designer, and one dev-ops member in our hypothetical team. They will dedicate ten hours per week to the project, and one of the back-ends will be the squad leader. Every two weeks, they will have a two-hour call to discuss the current status and decide what they will do next. Additionally, they will use Slack, Github, and GSuite for synchronization.

In conclusion, I would emphasize taking the upper statements with a grain of salt. They helped me in my previous experiences. I have used side hustles from an early age to keep myself in shape and learn new skills. For example, I took my bachelor’s and master’s degrees and worked full time simultaneously. However, such dynamics will take their toll on most people quickly and could even lead to burnout or diseases. Given that, I would advise you to choose your teammates carefully – not everyone is “crazy” enough to live such a lifestyle.

The minimalistic Start-Up – The Setup

February 6, 2022 /

In the following weeks, I shall write a couple of blog articles focused on how you can build a fictionary technical product on an extremely tight budget. The product will be defined as a side hustle, which idea will be to restructure, rewrite, and put into a modern shape an old project. We shall try minimizing the amount of time and money spent on the product because side hustles do not pay bills most of the time. At the same time, the approach will show how little is needed for a technical team to create a product and release it.

But what will be the idea – A simple tool that improves the way users plan their work. There are tons of such solutions on the market, and big companies have been developing something like that since the 90s of the last century. Keeping in mind that – we would like our fictionary product team to use new work approaches, check whether they can form a highly effective team, have some fun and focus their attention on something constructive. Of course, in reality, there will be no chances of scaling such a project. In addition, side hustle teams lose their energy and motivation to work long-term. In real life, people shift priorities – they can start working at a big corporation. Some had to focus on their income sources. Others got kids.

You can see a standard Gant chart on the diagram, used in almost every project management and planning solution. Our fictional team will use it heavily during their product development

Such a mental example could be beneficial for every technical team despite these facts. In our fictional situation, the team will manage to make an initial version of the tool; make a website; produce a video; write a couple of technical whitepapers; create “branding” elements, and improve their skills during the period.

In the following parts of this series, I shall explain and discuss how this team will manage to achieve all of this in their “free” time and how much it will cost them in terms of money. Every part will be focused on one of the following items – branding elements, website, video, technical whitepapers, and finally, team structure and way of work. Hopefully, this will help you build your product and structure your team using the same tools and approaches.

The good, the bad and the ugly of the proprietary software model

January 15, 2022 /

The last article discussed the advantages and disadvantages of the Open Source software model. We even listed some uncomfortable truths regarding its economic viability and how it could be more expensive than many proprietary products. Despite being an Open Source zealot, I want to start with the statement that I still think proprietary software is sometimes better than Open Source ones. We can not compare my case with the average customer because I have spent the last 18 years working in IT – aka I want much more control over my system than the standard PC user. At the same time, when I can, I strongly avoid using proprietary software because I want to know what runs on my device or have the ability to review it if I wish. But let me list the good, the bad, and the ugly of using proprietary software:

The good

  • Legal responsibility: Wishing or not proprietary software vendors are obliged by law in most countries to take care of their customers and the data coming with the usage of the software. And yeah, many governments try defending their citizens and their data.
  • Better support: No one will pay for proprietary software if support is not included in the price. The difference to the Open Source vendors is that you receive some hours of first-level support with the cheapest plans, which is better than nothing.
  • Centralization: Having a more centralized way of management has advantages such as faster development speed, faster decision-making process, and fewer intrigues. 
You can see a comparison between BlackBox and Whitebox software on the diagram. Open Source software is considered Whitebox because everyone can see and review its logic. On the other side, proprietary is considered as BlackBox because to analyze its behavior, analysts must use reverse engineering techniques

The bad

  • You should pay for it: One of the bad things regarding proprietary software is that people should pay for it. And the main problem is not the cost but businesswise; when you are using something you don’t have access to, you introduce a critical business dependency. What happens if suddenly this software vendor disappears?
  • Closed ecosystem: Decisions are made by the company’s owners producing the software. Customers usually do not have control or involvement in feature design and implementation. 
  • More complicated collaboration: If two companies want to work together, they should sign a contract, and by signing this contract, they “decide” how their partnership will happen. By not having a ready-for-use framework, lawyers must review every agreement and make sure that both sides are happy with it.

The ugly

  • Sometimes less secure: Proprietary software has the same security problems as Open Source software. Many hackers are pretty adept in reverse engineering and finding security holes. Additionally, proprietary vendors must pay for security audits and could not rely on an ecosystem of hardcore software engineers to do that for them.
  • Lousy support for smaller customers: The bigger a software vendor becomes, the lousier its support becomes for its small customers. And this equals them to the Open Source software vendors without support for their free plans. And yeah, there is a reason for the number of jokes regarding the quality of support provided by given operating systems manufacturer :-).
  • Weaker legal defense: The bigger a software vendor becomes, the more legally powerful it is. And this leads to fewer opportunities for its small customers to search for justice. Usually, the side with the bigger pool of resources is the winning one in legal battles.

In conclusion, there is no significant difference between proprietary and Open Source software models. The only meaningful difference is that customers could legally claim stuff easily from smaller proprietary vendors. However, once the vendor becomes too big, they hire better lawyers, and experienced lawyers are pretty good at defending corporate interests. Other than that, the tradeoff for the end customer is first-level support versus free usage.

The good, the bad and the ugly of Open Source software model

January 9, 2022 /

I want to start this post with the statement that I am a fierce supporter of Open Source, and all of my computers, servers, and smartphones are using different flavors of Linux. For the last ten years, I have used Windows ten times at most, all of this because some software vendors have been neglecting the Linux ecosystem for years. Other than that, I have no wish or necessity to touch Mac or Windows for anything rather than testing web or mobile apps. 

At the same time, I want to strongly emphasize that Open Source as a model has its problems and that I believe no software development practice, Open Source or proprietary, is ideal. This post aims to list some of the advantages and disadvantages the Open Source model has. Despite its widely successful spell during the last 30 or more years, the model is somehow economically broken. But, let’s start with the lists:

The good

  • Open Source is almost free: Most open source projects provide free plans for casual users or tech-savvy customers by having an ecosystem. This way, a whole set of companies can build their business model based on these freemium plans and add value.
  • More openness: People working on open source projects must make an ecosystem. And people stay in any ecosystem only if the system is open to proposals and changes according to members’ needs. In another case, the ecosystem usually does not survive for long. Additionally, everyone can review the code and search for security holes.
  • Better collaboration: Legally speaking, if two organizations want to work together, they should sign a contract on every point they want to collaborate. Organizations already know how to work with the various Open Source licenses and do not need to reinvent the wheel for their specific case.

The bad

  • Lack of responsibility: Most Open Source software comes without any obligations for the authors. Whether there are security holes, bugs, or losses by using the software – authors are not responsible.
  • Too much decentralization: When a project becomes too popular, the lack of centralization increases politics and power struggles. By having multiple controlling bodies or boards of people governing the project, the number of interested parties increases and thus sometimes making the decision-making nightmare.
  • Lack of support: Some Open Source projects entirely lack technical or user support. Even if they offer support, the customer must pay too much money to get any meaningful help. The plans with the lower cost usually are not helpful enough.
On the diagram, you can see a standard crawler architecture diagram. Most of the products implementing this diagram would use Open Source components to speed up the development and lower the cost. They must live with the problems derived from using these components

The ugly

  • Sometimes less secure: Many projects do not have the proper set of resources to ensure their level of cybersecurity, despite being used by many people. A recent example of that is log4j – all major Java products use it, and at the same time, a big security hole was discovered a couple of weeks ago.
  • Complicated business model: Open Source is complex for monetization. Many products try surviving on donations or support. However, this monetization model does not scale as much as the proprietary one.
  • Legal mess: Usually, proprietary products step on Open Source ones to speed up the development time. This technique is used primarily in Start-Ups or consulting companies. However, this approach has its problems. What happens in a similar case such as log4j, where a security hole or a bug in one of your Open Source components leads to data leaks or financial losses? Who is responsible? By default, this is the user of the component, aka you.

In conclusion, Open Source is not for everyone. It could be more secure or with better support, but only if the code comes from a reputable software vendor. In all other cases, the user is left on its own to handle their security and support. Another question is whether the alternative (using only proprietary software) is better, but I will analyze this in another article.

Cybersecurity tactics for small teams – Business Security

November 6, 2021 /

In the last couple of months, we discussed how you could achieve a good level of personal security for your team members. We covered the topics of physical information security, home network security, and finally, your hardware devices cybersecurity. With this article, we shall cover the issue of how you can upgrade your cybersecurity defenses as a team. The article will cover the necessities of remote-first groups because they are harder to defend. You can use the same approach to protect your office or shared space-based team. Still, the focus will be on underfunded small groups. At the end of the article, I shall present a sample budget for your team infrastructure.

But before going to the budget, let’s analyze how a remote team of workers communicates and collaborates. I shall list down the different infrastructure requirements for a technical IT team. Keeping in mind how digitilized our World is, they will work fine for any other distributed team.

Communication Channels

For every remote-first team, it is essential to have a communication channel. We can categorize the different communication channels by their speed. But let’s do this in the following list:

  • Email: Email is usually categorized as an official communication channel, which we can use for communication inside and outside of your organization. It is heavily asynchronous, with messages response going from minutes to days. Usually, this kind of communication is used for strategic discussions and long-term plans. That’s the reason it could be the most valuable target for an attacker.
  • Online Chat: Online chats are a faster way of exchanging messages. Usually, they are used when you need a quicker response from your peer, and there is no good time for a short, not planned call. Usually, the rule of thumb is to spend no more than 15 minutes chatting, and if the issue is not resolved, move to something faster. This one will be the second most significant target after the email for an attacker.
  • Video Conferencing: This one is the fastest. Usually, it is used to exchange a burst of already prepared information. Most of the time, the data is a tactical one, and thus this way of communication is with the lowest priority for attackers.
You can see a standard corporation infrastructure on the upper part of the diagram, where you have multiple zones and a load balancer. On the lower part is the typical small team setup, where all the data for communication is going through one cloud provider and one zone

Information Storage and Sharing

These days everything is done using information and files. But, you must store these files first and, after that, share them with your team members. Doing this using the standard communication channels is no good because there are no excellent categorization and tagging tools implemented in these systems. In short, they are not appropriately tailored for this kind of activity. That’s the reason the IT industry created a good amount of tools for solving this problem. Our small team will use them as well. So let me list them:

  • Project/Product Management System: Project management software (PMS) can help plan, organize, manage resource tools and develop resource estimates. Depending on the sophistication of the software, it can manage estimation and planning, scheduling, cost control, and budget management, resource allocation, collaboration software, communication, decision-making, quality management, time management, and documentation or administration systems. As you can see, most of the vital information for your project/product will be in this system, making it an excellent target for an attacker.
  • Cloud Storage Solution: Project management systems are outstanding in documentation storage, but they lack some of the features a full-scale cloud-based storage solution can offer. In this kind of solution, you usually store big files in a format such as video, audio, high definition graphics, etc. As such, you can leave a big part of your intellectual property lying in such cloud storage, making it a good target for an attacker.
  • Automation System: Especially in IT teams, sometimes your team will need automated jobs to happen. If you have automation specialists, know how to write scripts, you can automate a big part of your daily routes. In the case of programming teams, this is usually building, deploying, and testing procedures for a new version of your product/project. It means that you have to give access from your automation system to your programming code, for example. And this makes it an excellent target for an attacker. 

As we already discussed in the upper paragraphs, you need at least these six types of systems working and secured to have a functional remote-first team. Coming back to our knowledge of network defenses, the ideal solution for these systems is to be defended by VPN or a similar solution and expose only port 25 of the email server to support external communication. 

Unfortunately, this kind of setup will be possible only if you deploy the services in your infrastructure. In the case of cloud providers, you don’t have much control of what is exposed to the Internet and how the cloud provider takes care of your security. Plus, the infrastructure is shared between multiple organizations, and there is no guarantee that these organizations follow such strict cybersecurity rules, such as your team.

Budget

 But anyway, let’s create a budget for on-premise deployment of your infrastructure, and we shall use a VPS provider because it will be cheaper for us. A virtual private server runs its copy of an operating system (OS). Customers may have super user-level access to that active system instance, so they can install almost any software that runs on that OS. For many purposes, it is functionally equivalent to a dedicated physical server and, being software-defined, can much more easily be created and configured.

The most famous VPS providers are Amazon Web Services and Microsoft Azure. Still, there are some smaller players, such as Digital Ocean and Hetzner. As we shall do the infrastructure for a small team, we shall need a VPS with a not big pool of resources and go for the lowest price, which means CX1 instance in Hentzer. So let’s list now the different servers we shall need. All the prices are per month.

  • Email And Chat Server(3.57$): As there will be no significant demand for these two services, we can place them on the same machine.
  • VPN Server(3.57$): We shall have one machine for the VPN server, and all of the services without port 25 will be behind this VPN.
  • GitLab Server(3.57$): Gitlab is a project management/automation system. As it can become quite a hungry beast, a standalone instance is a way to go.
  • Video Conferencing Server(3.57$): One more hungry beast, it is a good idea to have it as a standalone server.
  • Cloud Storage(9.31$): This one will be a CX1 instance + an additional 100GB to store larger files. For a small team, a total of 120GB will be enough.

With a total budget of around 23.59$ per month, we achieved a pretty good level of security. Still, a determined attacker can penetrate this setup, but it will take him more time and resources. We shall use the standard VPS provider firewall. Still, if we want to achieve a higher level of security, we could add a server that will serve as a software-based firewall and IPS solution. Additionally, there are Open Source solutions for all the services types, and they will cost us 0$ per month.

Agile for Start-Ups – part 2

November 4, 2021 /

In the last article, I shared the usual disadvantages when teams use agile methods in early Start-Ups. In this part, I shall give you my list of modifications and changes over the standard agile workflows. All of them are based on my experience and errors accumulated during the years working in underfunded Start-Ups. Additionally, I shall give you additional information regarding how it can affect team morale and motivation for every modification. But let me list the different changes I used during the years:

  • Do not do peer reviews: Peer reviews work pretty well for improving code quality and knowledge sharing. However, they are one of the biggest bottlenecks in your team workflow. Additionally, to have productive peer reviews, the peers must usually be at the same level of expertise. The best case is for the reviewers to be with more considerable expertise than the reviewed. For early-stage Start-Ups, I would suggest senior management appoint two or three people to do all the code reviews in the company. With this approach, team morale and motivation will increase because you would avoid much friction and drama.
  • Avoid unit tests: Unit tests are one of the best ways to increase your code quality. However, during the early stages of your product, where you do a lot of research and expect significant refactoring of the code base, unit tests, constant maintenance can kill your velocity and hurt your team morale. Usually, after the initial effort to create the tests, the team stops maintaining them after a couple of tight deadlines, and finally, they are entirely disabled. Better spend your time doing integration, smoke, or component tests because they work on established APIs, and these APIs do not change dramatically.
On the diagram, you can see the traditional technical team structure of four layers. In early-stage Start-Ups the positions CTO, Head of Development, and Team Lead are usually held by the same person
  • Don’t be sloppy with your architecture: Make sure your technical architecture is solid and can be upgraded or refactored easily. Quality of code is not so important because you can improve your code quality quickly, but not your architecture. Many teams decide to start with less complex architecture, and after that, they have to reimplement the solution. Better, plan how you are going to implement your architecture in phases with change in mind. Start with only the essential components and upgrade them later. Doing something twice is the most significant morale and motivation killer in one team.
  • Do not estimate R&D: Early-stage Start-Ups usually must not plan research and development. It would be best to entirely avoid research and development and work on already established business or technical models with minor modifications. Innovation is expensive in terms of time and money. It should be avoided or minimized as much as possible.
  • Threat every task as a different sub-project: Many company owners love to categorize their products using the famous triangle of quality, speed, and time. However, the major mistake is that a software product is a collection of submodules. And every submodule comes with its complexity and implementation. It is much better to treat every submodule as a separate project and decide what we expect using the quality, speed, and time triangle.

In conclusion, these are my leading suggestions for every early-stage Start-Up team. To extend your Start-Up life, you should cut time and resources from every non-essential part. My proposed list gives some hints in that direction, and I am sure you could create your lists by filtering what the essential and not the essential activities in your team are.

Agile for Start-Ups – part 1

October 28, 2021 /

I want to start these two articles by observing that I don’t believe agile methods are appropriate in their proper form for Start-Ups. In the first article, I will list most of the disadvantages of the agile methodologies and how they could hurt the Start-Up’s performance. In the second one, I shall present what worked for me in the past and what did not. 

But let’s start with little history of the product management frameworks and how they evolved. Historically the initial management framework was the so-named waterfall or phased approach. With that approach, the companies copied how most engineering products are created by multiple phases and initial requirements gathering. This way of working does an excellent job when you want your solution to be installed on-premise and must work for a long time without interruption. 

In the 80s of the last century, Watts Humphrey, during his work at Carnegie Mellon University, founded the Software Process Program, and with that, he started the so-named PSP (Personal Software Process). This process heavily relies on not comparing the performance between different developers but rather trying to improve every developer as a single unit. Additionally, in PSP, we have the notation of knowledge re-usage – aka if the developer has implemented something similar as a block in the past, we could expect him to implement such block with the same speed.

In 1986 Hirotaka Takeuchi and Ikujiro Nonaka started Scrum and the foundation of different agile methodologies. At its core, the agile development process defines that the “customer/client/company owner” will work together with the team and provide business knowledge and requirements weekly. A fundamental principle of Scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility) and that there will be unpredictable challenges — for which a predictive or planned approach is not suited. These changes come from various sources, but understanding why is irrelevant: change should be accepted, embraced, and analyzed for benefits.

On the diagram, you can see the standard agile workflow. Its typical duration is between 1 and 4 weeks. In Start-Ups, the main problem is during the planning meeting because it is impossible to plan R&D

And now here are some reasons they do not work well for complex Start-Ups:

  • R&D: All of the listed methods work on the assumption that the team will not do any research and development. Aka, the business owners know their business niche and that someone else already did the R&D part. In reality, this rarely happens, except when we start a business without any innovation. When you want to make an innovation, all traditional product management frameworks stop working. Usually, in the Start-Up World, the team must do R&D and code writing simultaneously (investors and clients want to see progress).
  • Burnouts: Constant changes in business requirements and business situations usually involve many changes in the technology stack and your programming code. Sometimes you must rewrite the whole product from zero. And this typically takes its toll on the engineering team. For sure, if you do not manage to make business traction (aka finding clients) for the first three years of your Start-Up, it is virtually certain that this lack of progress will demotivate your technical team, and most probably some of the members will feel the effects of burnout.
  • The process will not mitigate your people’s weaknesses: According to most agile methodologies fans, these methods are the panacea for every technological problem. However, we have to ask ourselves why only 5% of the Start-Up technical companies pass the second year of work? All of them use these methodologies. For sure, we could blame the business development and marketing, and we will be right that 70-80% of one successful business is the way you sell. However, at the same time, I saw many technical teams struggling in their performance because of leaning too much on the agile principles.

In conclusion, I would want to emphasize that no product management workflow in the World will mitigate the weaknesses your team has in the first three years of your Start-Up. The only way to increase your team productivity is by training them, and by training, I mean the business and the psychological part of being into a Start-Up. Technical knowledge is much easier to adopt and realize than handling that your odds of winning a VC are 1:300.

Could Open Source be successful for Start-Ups

October 21, 2021 /

For a long time, I had this discussion with colleagues and friends about whether open source technologies, especially Linux, could replace all of your software needs. In the past, the main problem regarding using Linux was not mature enough ecosystem and being too complex to work with. However, after the introduction of Android (we could categorize it as a Linux distribution), things became less difficult, and many companies invested much of their time into making their products work on Linux. 

But still, something is missing. By official data, the Desktop Linux users are between 0.6 and 1.5% of the overall Desktop Users. And this is quite a low count of Desktop users. It seems free is not enough for business owners to make the shift. But let’s compare the traditional business software stack to what Linux can offer:

A typical modern office setup, in which there is a data center with servers, and all of the employees are using these servers to connect to their corporate network and use the systems
  • Microsoft Office and Outlook: LibreOffice is an excellent alternative for having an on-premise installation of the office software package. It usually has good compatibility with the original Microsoft Office and could open and edit files. Sometimes the styles of the original files are destroyed. In that case, one can use the cloud variant of Microsoft Office in a web browser. This way, we could avoid such issues. Additionally, Linux comes with Thunderbird, which is an excellent alternative to Outlook.
  • Zoom/Viber/Microsoft Teams/Slack: All of these have binaries for Linux, which means you could have the standard video conferencing apps installed on your machine and have the same experience as the Windows-native users. Additionally, they all support web browsers, which means no need for a native app for communication.
  • Exchange/Sharepoint: Most Linux distributions do not support an active directory out of the box. However, one German distro supported all the group policy features and made it possible for Ubuntu-based clients to connect to this active directory. The name of that distribution is Univention Corporate Server and could be used as a drop-in replacement for Windows Server.
  • Specialized Software: And usually, here comes the main problem with Linux. Most of the specialized software does not have builds for Linux. Some examples are Adobe Photoshop, Adobe Illustrator, 3D rendering software, most of the accounting software, most of the governments’ software, etc. Unfortunately, there are no signs of bringing this software to Linux soon. Fortunately, most of the workers in a given company do not need highly specialized software, and they could do their job in the web browser.

In conclusion, using Linux in the corporate environment has become more and more user-friendly. At the same time, I firmly believe that Linux could entirely replace the software stack for SMEs, excluding those using the specialized software. Fortunately, there is a shift in software development for going into the cloud, which could, even more, help the SMEs with the specialized software (some vendors are already moving their software in the cloud). Additionally, all Linux distributions support Firefox and Chrome out of the box. And as a final – during my coronavirus sick leave, I managed to open my X-Ray photos (DCM image format) on CentOS 8 (I have been using CentOS for the last up to 10 years) without installing anything. ImageMagick supported it out of the box.