by Dasha Gurova | Jul 30, 2019 | Stories
Open Source Software (OSS) Compliance is all about giving credit where credit is due and following the terms of use. Not doing so destroys others’ trust in you.
Complying is as easy as:
- Find your software’s build/run dependencies
- Find licenses for them
- Do what the licenses tell you to do
Sounds pretty straight forward, right? Enter the complicated world of containers!
Don’t get me wrong, we love them. Zenko is a distributed application packaged in Docker containers and orchestrated by Kubernetes. This architecture makes it possible to deploy your software almost anywhere, benefit from agile development workflows and ensure continuous uptime. But with great power comes great trouble, too.
Anatomy of a container
In established areas of open source software, it is well known that distributing software means inheriting all the license obligations of the dependencies. But when it comes to cutting-edge technology like containers it is almost like the “wild wild west” out there. Why is the landscape of tools and practices for OSS compliance in containerized applications so limited?
Although we have been using containers to ship applications for a relatively small period of time, the adoption of it was so fast that the compliance part has been almost ignored. The ghosts of failing to comply with OSS are now coming back to haunt us.
I covered Docker container security issues in last week’s post, and I think those two issues (security and OSS compliance) are related and have similar challenges. Both security vulnerabilities and failing to comply with open source licenses come from the same place – the shady nature of container images.
How a Docker container is usually created:
- We download some images from a public repository to use as a base. At that point, all that gives us is a collection of tarballs containing files.
- We copy our application to the container (probably the only files that we know anything about).
- We execute scripts to install dependencies, build binaries, etc..
- We upload the resulting image to a repository.
This image is now shipped to the customer or other users. Now we are distributing not only our application but everything inside this image, and we are responsible for complying with all the licenses.
OSS compliance for containers
You should set up your compliance strategy from at least two angles.
Angle 1 – Control the process of creating and building images
Use only “known-good” OS base images, where you know you can get the list of all installed software along with licenses and sources (for example, Debian’s package manager can do that). On top of that, use build manifests to install the software you need and keep track of it. Avoid using Docker multi-stage build functions, as they are not reproducible.
Angle 2 – Employ scanning tools
I want to make one thing clear right away – there is no tool that will take care of everything. You need to put a process in place that combines scanning Docker images with manual checks and research.
Tools from Linux Foundation
The Linux Foundation recently launched the Automated Compliance Tooling (ACT) project in an attempt to drive and help with OSS license compliance. There are four projects that are part of ACT you should check out:
- FOSSology – an open source license compliance toolkit letting users run and export license and copyright scans.
- QMSTR – this tool creates an integrated open-source toolchain that implements industry best practices of license compliance management.
- SPDX Tools – Software Package Data Exchange (SPDX) is an open standard for communicating software bill of material information including components, licenses, copyrights and security references.
Container compliance scanners
- VMware also donated its Tern project to ACT to help cover compliance automation in the container space. It offers a couple of different formats for the scan results. Deployment options: Docker, Vagrant, Linux.
- Another tool I came across is Container-diff – it analyzes images in a similar way as Tern, but offers a comparison between two images. You can use this to keep track of changes made to different versions of your images. Deployment options: Linux, macOS, Windows.
Container security scanners
Security scanners are another set of software that can help you with container images. The variety of tools in this domain is more robust, maybe because security breaches are can get far messier than OSS compliance. You can use these scanners not only to check against known vulnerabilities but also as a way to produce a very thorough SBOM (software bill of material). These tools in their essence are scanners that decompose container images to building blocks (dependencies).In my humble opinion, those are leading the pack:
To learn more and see the longer list, check out my previous post on Docker container security tools.
What did we learn?
We should be more mindful when reusing Docker images and building on top of them. It is also necessary to create a workflow that includes some automation tools (scanners) and manual checks.
With more developers and leaders talking about the importance of open source compliance, hopefully, we will soon see shipping fully compliant containers as a normal, more streamlined practice. As it happens, tooling will evolve automating the process and making it easier.
Share your thoughts or ask a question on the forum.
by Shivani Pradhan | Jul 23, 2019 | Stories
Are you considering taking the leap from Engineering lead to a management position? Managing people is indeed a dramatic change in career path and requires a different set of skills than needed for a technical lead role. When I recall some of the hardest management experiences I ever had early on in my career it was always the people aspect that challenged me the most and this is one area where you just can’t have enough experience.
As an engineer, you are responsible for technology: for your features’ design, execution, and delivery. In a management role, you are responsible for people and your prime job is to empower and enable your team, set strategy for the team, unblock folks, communicate with stakeholders, enable sales, pre-sales, and proofs of concept, support technical services and customer-facing teams, and––above all else––manage people’s careers.
As a leader, you are the star performer, stepping up and helping the team put out fires, but as a manager, your job is to put others in your team in the spotlight. You are in a coaching role and that comes with a lot more responsibility. As they do well, you will get credit for leading them well, and this will shift your focus from coding to the most time-consuming aspect of being a manager—people management.
After a decade I continue to learn and grow, with new experiences every day dealing with situations that feel unique, yet morphed from situations I’ve seen before. Though I have been blessed with great mentors throughout my career, there have been occasions where I fumbled. One thing I quickly learned was to own up to my mistakes, study them, and learn from them.
As a new manager you are eager to succeed, and when a person in your team doesn’t pull their weight or messes up, it is very tempting to make an example of them, make them the martyr, and let them face the consequences in the name of accountability.
Learning to avoid this dynamic was a turning point in my career, and helped me to be a leader and not a boss. This is not a one-time opportunity and this will happen way too often as you become a manager. It will be hard to take the bullet for the team in front of your own manager, especially for folks that you can clearly see could have been proactive and prevented a fire or worse procrastinated in putting it out and let more damage happen.
You owe it to everyone on your team (not just your friends) to be a neutral, unbiased, trusted resource. For the rest of the organization, accountability stops at you. Your job is to guard your team’s back. Something no one told you: from time to time, you will need to not only take a bullet for your team but make tough unpopular calls and—an unfortunate fact of life—it is lonely as you move up the ladder.
Why do it?
Simply put, you have more influence, and you can enable people in their pursuit of a meaningful career! It’s a truism that people don’t leave jobs, they leave managers. How well your direct reports perform is a reflection of your own effectiveness as a leader. Your scope of influence increases dramatically when you move from individual contributions to the head of an entire team.
Sure, as a star performer in the team you make significant contributions to the team’s wins, but as a coach how the team plays—its camaraderie, unity, coordination, strategy and execution rest on your shoulders. In The Power of Small Wins, a 2011 Harvard Business Review article, the authors recount the famous exchange between Steve Jobs and John Sculley over Sculley’s future with Apple:
In 1983, Steve Jobs was trying to entice John Sculley to leave a wildly successful career at PepsiCo to become Apple’s new CEO. Jobs reportedly asked him, “Do you want to spend the rest of your life selling sugared water or do you want a chance to change the world?” In making his pitch, Jobs leveraged a potent psychological force: the deep-seated human desire to do meaningful work.
As a manager you are being entrusted to enable, empower, and lead others to do more meaningful work than you could as an individual contributor.
Tips to help you succeed in a managing role
As anyone with administrative privileges knows, with greater power comes greater responsibility. You will be in situations to make tough decisions, controversial ones—you may even have to fire an employee reporting to you. Build trust by being honest and sharing professionally what you can. Moving to a management position will affect your friendships with your colleagues. As I said before, it’s lonely as you move up the ladder.
It is very important to be emotionally intelligent. Practice self-awareness and being aware of your emotions and how they affect your handling conflict or viewpoints you don’t agree with. Practice self-regulation: what works to calm you down when you’re angry and what helps motivate you when you’re down and depressed. Practice empathy with your family and close friends, which will improve your social networking, communication and leadership skills. As a manager, you will have access to a lot more vital information and you must stay professional and respect boundaries. You will need a support structure and for that you need to anchor with your family and friends and not take them for granted.
Over the years I have learned that the simplest way to establish mutual trust and respect between me and my team was by being as honest as I could be. I had to be conscious to not complain and whine about my own issues to my old teammates anymore.
Being promoted to management is a huge milestone that directly acknowledges the faith of your senior management in your ability to lead. In my own case, as an early manager, I was very conscious of not reaching out to upper management with the fear of being judged as incompetent, not ready for the job. If I told my manager I can’t figure something out, would he start getting second doubts that he shouldn’t have promoted me in the first place? Imposter syndrome was there to stay until I figured it out.
You will have moments of self-doubt and some self-doubt is a good thing. Self-doubt enables us not only to reflect but also to look for validation and to be open to feedback. In the right measure, self-questioning keeps you learning and growing and also keeps you humble. Humility, in turn, makes it easier for you to listen and learn.
Embrace opportunity when it comes your way and build trust with senior management. Don’t hesitate to ask for advice, insights, and scenario discussions with experienced leaders in your network and company. Your management believes in you enough to offer you this opportunity, and your managers may well know better than you what you’re capable of achieving.
by Shivani Pradhan | Jul 19, 2019 | Stories
We all want more performance from systems but what does that even mean. Is Performance ever enough? What’s the threshold below which it doesn’t actually make much sense to optimize? We ask ourselves questions while testing Zenko and other Scality products.
Your system is going to be only as fast as your slowest component and today’s everything as service world, the network performance more than often governs or dictates what a user sees as the performance of the system.
How to define network performance?
Consider a network connection as a highway and the IO chunks as vehicles. Larger IOs are like big trucks. Let trucks be represented by 1 GB data chunks while small IOs like 512-byte, a 1 KB, 2 KB, or even a 4 KB chunks are like bikes.
Sometimes it is more important to carry a large number of packets and other times, it matters how much data each packet can carry, determining the capacity. To speed up the supply of milk cans to a city, it makes sense to use trucks. This maximum rate of data transfer that shows the capacity of the network link is called bandwidth. This is typically measured as KBps (kilobytes – thousands of bytes per second), MBps (megabytes – millions of bytes per second) or GBps (gigabits – billions of bytes per second). A mile stretch of four-lane freeway has more capacity hence more bandwidth for cars than a two-lane road.
Throughput is the number of messages successfully delivered per unit time. Say, the goal is to increase the number of people making it to the workplace on a busy morning. If every person decides to drive a truck to work, we fill up the highway very quickly and only a fraction of people make it to the workplace as compared to if every person is on a bike.
Measured in IO per second, throughput is the rate at which vehicles pass through the highway in unit time. If your highway is full of big trucks (that is if the IO size is very large), you can fit only a few of them on the road but you can carry large quantities of data.
Applications that have high throughput requirements generally also are latency-sensitive and use smaller IO sizes.
Bandwidth is high if we use large trucks (large packets to carry more data), while throughput (IO/sec) is high if we use bicycles (small packets so we can fit more packets). Applications that have high bandwidth/high capacity requirements use larger IO sizes. As bandwidth increases, throughput decreases and vice versa.
The time it takes for a request to travel from the sender to the receiver, for the receiver to process that request and send an acknowledgment back is known as latency. It is basically the round trip time from the browser to the server.
Performance for a product is typically defined in terms of throughput, bandwidth, and latency.
How much performance is good enough?
Performance is the user’s perception of expectations from the product and its usability. Because users’ perception is susceptible to distortion, what users perceive or expect may differ from real product performance. It is hence extremely important to do performance testing to be aware of performance bottlenecks. This will help establish an intelligent service level agreement (SLA) that provides accurate guidance on capacity and scalability. With this information, a customer can avoid a potential scalability problem in production. Correct performance testing on the right use-cases and workloads is very important to ensure the product complies with customer’s business requirements. Performance testing must take into account not only how the business is expected to grow but also the rate of expected growth.
As developers work hard on optimizing performance, it is critical to understand the concept of “just enough” or “minimum improvement needed to be even noted”. The Weber-Fechner Law involves a key concept called just-noticeable difference, the minimum increase or decrease in magnitude of a property before it becomes noticeable. Put simply, for an improvement to be noticeable by a typical user, the stimulus must be 20% more in magnitude.
Denys’s Mishunov blog on perception of time explains the 20% rule as well as the concept of performance budget and optimization. The 20% rule applies not only to improvements but also to regressions. Letting your code be a bit slower as long as it is not harming the user experience is called a regression allowance: the typical user will not notice if the end-to-end impact is less than 20%. This in no way means we shouldn’t seize opportunities to optimize our code and improve its performance, but it does enable a better cost-benefit analysis of whether a 5% improvement is worth six weeks of effort.
Performance testing must assess user experience in realistic scenarios on the target application and attempt to simulate real customer use cases. A standard performance suite has functional and end-to-end tests that measure component performance as a part of code quality and validation efforts. In a more comprehensive suite, load, stress, and soak tests play an important role in truly characterizing the product’s performance.
- Load Scalability Test: A load test consists of applying increasing loads to an application and measuring the results. As load grows to the high end of application capacity, these tests often overlap with maximum-capacity/end-limit tests. A maximum-capacity test determines how many users an application can handle before either performance becomes unacceptable.
- Stress Test: A stress test drives an application beyond normal load conditions. As application boundaries are pushed to the extreme, these tests typically expose the weakest components in the system by exposing failure on those before others. Making these components more robust helps raise limits and find new performance thresholds.
- Soak Test: A soak test is a long-running test, also known as a golden run, that determines application performance or stability over a few weeks. As a dedicated system keeps running soak tests while periodically upgrading exposed issues like memory leaks, corruption issues that only manifest over long periods appear.
To simulate the customer’s use cases accurately, you must understand the customer’s workload. Each workload has unique characteristics, and each of which impacts storage latency, IOPS, and throughput. A workload is defined by:
- How much a typical user reads or writes (or both).
- Whether the user reads/writes are sequential or random (if reading sequentially, caching can help; not so for random reads. Sequential performance numbers are generally higher than random performance because of caching effect).
- The number of threads and whether those threads are parallel or concurrent:
- The input/output (IO) size.
Other workload characteristics you must take into account:
- Metadata workload must be characterized separately from data.
- Other impacts, such as deduplication, compression, or encryption, must be accounted for.
Workload characterization
A workload is a set of I/O characteristics running through a group of containers or VMs that interface with compute, network and storage infrastructures. A typical application workload may interact with a web server, one or several database servers, as well as other application servers. The combination of all of these servers and the associated networked storage makes up that application’s workload.
Let’s look at defining an online banking workload. All SSL-based requests are for web pages, followed by requests for embedded images and other static files associated with the page. A page is fully received when the file and all files associated with it are received. The IO profile in this example is 95% reads and 5% writes (i.e., 95% GET and 5% POST), and a 100% request success is assumed. Twenty-five percent of the requests are for static files that can be served from the cache, which returns a “304 not modified” response. When a request is successfully processed, the server returns a “200 OK” response code.
A typical social media workload is 95% read and 5% insert. The free Yahoo! Cloud Serving Benchmark (YCSB) simulates many types of database transactions, including a read-dominated eight-transaction mixture typical of most social media database activities and can be used to simulate simple social network user activities.
The above table is an attempt to explain the characteristics of a few workloads so they can be simulated for performance testing.
The online transaction processing workload (OLTP) typically seen in online booking, online banking, ATM transactions, retail sales, order entries is a heavy read–write mix (70r:30w) with v small IO size. Characterized by a large number of short online transactions (INSERT, UPDATE, DELETE), OLTP performance is measured in transactions per second hence throughput matters the most. Low latency is important.
OLAP, the online analytical processing is the data warehousing workloads where large amount of data is processed, streamed, combined, filtered for forecasting, data mining, online data queries etc. The workload is dealing with huge quantities of data. The original data is read but not modified. IO sizes are generally large and bandwidth dominates the performance characteristic.
Exchange is Windows mail server workload, characterized by 4K random read write mix in the ratio of 2:1.
Backup workloads are large (256 K and up) sequential writes to a backup device, generally with a maximum of four concurrent threads, whereas video rich media are sequential large streamed reads. The streaming workload has a 256 K or larger IO size to improve bandwidth.
Decision support systems are of various types. The most common technology used to deploy the communication based DSS is a client-web server. Examples: chats and instant messaging software, online collaboration and net-meeting systems, search servers etc. DSS (decision support system) is often categorized as read-only workload, with few large sequential writes (‘batch’ and ETL). It’s measuring criteria is GB/sec (bandwidth).
Hope this gives you some idea on how you drill down various aspects of workload and build on it to get closer to your specific customer scenarios.
Did you find this information useful? Do you have something to add? I look forward to your feedback. Please reach out to on the forum!
by Dasha Gurova | Jul 16, 2019 | Cloud-native apps, Stories
In this day and age, either you are already using Docker containers or considering using it. Containers have made a huge impact on the way teams architect, develop and ship software. No wonder – they are lightweight and scalable, and help us create an extremely portable environment to run our applications anywhere.
The problem with containers
To understand the problem we need to get our basics down. A container is an instance of an executable package that includes everything needed to run an application: code, configuration files, runtime, libraries and packages, environment variables, etc.
A container is launched based on something called an image, which consists of a series of layers. For Docker, each layer represents an instruction in a text file called a Dockerfile. A parent image is a base on which your custom image is built. Most Dockerfiles start from a parent image.
When talking about container images, we often focus on one particular piece of software that we are interested in. However, an image includes the whole collection of software that plays a supporting role to the featured component. Even a developer who regularly works with a particular image may have only a superficial understanding of everything in the image.
It’s time-consuming to track all the libraries and packages included in an image once it’s built. Moreover, developers casually pull images from public repositories where it is impossible to know who built an image, what they used to build it and what exactly is included in it. But when you ship your application along with everything that is in the container, you are responsible for security. If there is a security breach, it is your reputation that could be destroyed.
Container Scanners
It is so difficult to track what is going on under the hood of a container image. Image scanners have emerged to address this issue, giving users varying degrees of insight into Docker container images. Most of the tools execute the same set of actions:
- Binary scan of the Docker image, deconstruct it to layers and put together a detailed bill of material of the contents.
- Take a snapshot (index) of the OS and packages.
- Compare this bill of material from an image against a database of known vulnerabilities and report any matches.
Even though those tools are similar they are not the same. And when choosing one to use, you need to consider how effective they are:
- How deep can the scan go? In other words, the scanner’s ability to see inside the image layers and their contents (packages and files).
- How up-to-date the vulnerability lists are.
- How the results of the scan are presented, in which form/format.
- Capabilities to reduce noisy data (duplication).
5 tools to consider
Clair – tool from well-known and loved CoreOS. It is a scanning engine for static analyses of vulnerabilities in containers or clusters of containers (like Kubernetes). Static means that the actual container image doesn’t have to be executed, and you can catch the security threats before they enter your system.
Clair maintains a comprehensive vulnerability database from configured CVE resources. It exposes APIs to clients to invoke and perform scans of images. A scan indexes features present in the image, and is stored in the database. Clients can use the Clair API to query the database for vulnerabilities of a particular image.
Anchor – is a well-maintained and powerful automated scanning and policy enforcement engine that can be integrated into CI/CD pipelines and Docker images. Users can create whitelists, blacklists and enforce rules.
It is available as a free online SaaS navigator to scan public repositories, and as an open source engine for on-prem scans. The on-prem engine can be wired into your CI/CD through CLI or REST to automatically fail builds that don’t pass defined policies.
Below is an example of Anchor scan results of Zenko cloudserver Docker image (the list of Node.js dependencies)
Anchore Engine ultimately provides a policy evaluation result for each image: pass/fail against policies defined by the user. Even though it comes with some predefined security and compliance policies, functions and decision gates, you can also write your own analysis modules and reports.
Dagda – is a tool to perform static analyses of known vulnerabilities in Docker images and containers. Dagda retrieves information about the software installed into your Docker images, such as the OS packages and the dependencies of the programming languages, and verifies for each product and its version if it is free of vulnerabilities against the previously stored information into a MongoDB instance. This database includes the known vulnerabilities as CVEs (Common Vulnerabilities and Exposures), BIDs (Bugtraq IDs), RHSAs (Red Hat Security Advisories) and RHBAs (Red Hat Bug Advisories), and the known exploits from Offensive Security database.
On top of that, it uses ClamAV to detect viruses and malware. I also want to note that all reports from scanning the image/container are stored in MongoDB where the user can access it.
Docker Bench for Security – the Center of Internet Security came up with a solid step-by-step guide on how to secure Docker. As a result, the Docker team released a tool (shell script) that runs as a small container and checks for these best-practices around deploying Docker containers in production.
OpenSCAP – this is a full ecosystem of tools that assist with measurement and enforcement of a security baseline. They have a specific container-oriented tool, oscap-docker, that performs the CVE scans of containers and checks it against predefined policies.
OSCAP Base is the base command line NIST-certified scanner. OSCAP WorkBench is a graphical user interface that represents the results of the scanner and aims to be intuitive and user-friendly.
Wrap up
These tools appeared because Docker’s popularity has grown so fast. Only two years ago, it would have been hard to trust those tools as they only started to pop up. Today, they are more experienced with Docker containers and the challenges that came up with the rise of this technology.
Next week, I will go through other tools and scanners that are more OSS compliance-oriented.
That’s it for today. Stay safe and let’s chat on the forum.
by Shivani Pradhan | Jul 9, 2019 | Stories
One of the most influential books I’ve read on product design was The Design of Everyday Things by Don Norman. The principles are so universal that they apply to almost everything from a toaster to today’s advanced technological products. Here is a walkthrough of Don’s principles to influence our collective design thinking.
Visibility
A good design guides the user in knowing what the most essential features are by making them more visible. The key is to prioritize content and functionalities. The goal should be to reduce over-complexity, but not fall for over-simplifying either.
Users need to know what all the options are, and know straight away how to access them. We subconsciously weigh in the decision (cost) to click on something based on the perceived value (benefit). The most effective way of getting people to take action is to make the target action as simple as possible while ensuring maximum benefit. In order to deliver high perceived value in the form of good user experience. It is crucial to narrow down to functionalities that answer the user’s needs that guide them to the specific functions. In doing so you also want to make sure you aren’t letting the user get overwhelmed with too many choices. Letting a user get stuck in the decision-making process of “what next?” impacts the cost-benefit. Visibility and accessibility of important features directly relate to Hick’s law (increasing the choices increases the decision time algorithmically). Fitting too much functionality into a site or an application directly impacts and hurts the user experience.
While designing, it is important to keep in mind the Gestalt Principles of Visual Perception as often times, our visual perception is manipulated by spacing, proximity, color, similarity, symmetry, etc. We tend to fill in the gaps and follow the lines of continuity.
Here is a good example of visibility on functionality. This is a screenshot of Orbit, the SAAS based frontend of Zenko. The menu on the left categorizes the functionality into the following 6 categories and under each category, it exposes the core features in each category in a clear hierarchy. Also, by placing it in a prominent position and giving it a contrasting color, it stands out in the design. It is clean and simple.
- Monitor
- Dashboard
- Statistics
- Location Status
- Configure
- Explore
- Workflows
- Application
- Bucket Lifecycle
- Account
- Help
Feedback and Constraints
As the battery of a mobile device drains, the little battery symbol on the top of the screen gives us feedback continuously on remaining battery life. When we plug in the mobile phone, a small lightning symbol gives clear feedback that the power source was detected and the phone is now charging. It is the communication on action taken and transparency whether the action was successful or a failure. People strive for predictability and control, and in most cases, clear actionable information impacts better decision making.
Observe various system designs around you and note how they provide feedback on their current status. An elevator chimes before closing the door and chimes when it reaches the destination floor. A car today alerts the driver if they don’t have their seatbelt on. A simple LED turns on when most electronic gadgets are powered on. All these pieces of information allow you to accurately assess the current state of the systems you interact with. This brings up a great point from the book. “Too much feedback can be even more annoying than too little. Feedback must be thoughtfully planned in an unobtrusive fashion.” The key is balance and that’s where real art lives.
What’s equally important is preventing the user from doing the wrong thing– the concept of constraints. Constraints are powerful clues limiting the set of possible actions. Norman gives a great example in his book of a toaster. There is only one place to insert the toast making it hard for the user to insert the toast incorrectly. The thoughtful use of constraints in designs let people readily determine the proper course of action.
Another example from Orbit shows as the button is pressed, it changes color to provide feedback to the user. This is a clue that tells the user something is happening.
Affordance
Affordance, simply put, is the perceived understanding of what could be done with the product or feature. Affordances refer to the potential actions that are possible. For example, the presence of a knob gives the user a signal that this surface can be turned, pushed or pulled in some way. This is just like how our brain knows that slots are made for things to be inserted into. The idea is that once someone perceives a feature they know what steps to do to operate. An example of high affordance is a shoe — it’s easy to figure out intuitively how to use it.
Another example includes the mapping above ATM interaction. There are physical constraints in place to prevent the user from doing the wrong thing. The card insert slot is lit giving “feedback” that this slot is where you insert the card. The last screen has a clear white test box with a red button saying ”enter,” again setting a perceived affordance that this white box will take the pin. The box will fill up 25% with every digit. With 3 digits entered, the box only has space for 1 more letter letting the user know only one digit remains.
Below, Orbit shows the possible actions that can be taken on the screen by disabling or graying out what cannot be modified. It also shows what is “optional” and what can be entered to configure replication of this source bucket to another cloud destination.
Mapping
Mapping is the relationship between control and effect. In a car, if I locate the dial that controls the temperature, it is easy to discover how to operate. If I turn it clockwise, the temperature gets warmer. If I turn it counter-clockwise, the car gets colder.
A slider bar on the mobile phone shows the direct mapping between sliding the dot left and right and the screen brightness.
Consistency
Creating a new impressive product gets users to come to you, but having consistency makes users want to stay. A few months ago Atlassian changed the Jira design and caused an internet storm. People that were loyal customers were unable to easily transition to the new layout. This new design did not give users an incentive to continue using their product. Instead of knowing how to operate everything, people were stuck searching for every button and relearning steps to execute old habits. One big consequence of broad design changes come when your users’ licenses expiration occurs around the same time as the changes. Time and time again, you will lose more customers if they feel they are better off using a product that they know, where they don’t have to learn something new.
People invariably object and complain whenever a new approach is introduced into an existing product because it directly influences the usability principles like:
- Learnability – the user has to learn the new settings.
- Memorability – if the new setting is intuitive such that the user finds it easy to memorize, this would be a positive outcome. If not, it is not welcome. Old habits die hard. If you’ve trained your users to your functionality, consistency plays an extremely significant role in making things look familiar, no learning curve, bring more efficiency, and directly enhancing satisfaction.
- Efficiency – the user sees the direct perceived value and once the user has learned the new interface, they can see themselves using it as it is higher performance in the user’s eyes.
- Errors and recovery – user made fewer errors with this new design and had a better feedback loop or intuitiveness of new design prevented the user from doing the wrong thing in the first place
- Satisfaction – measures the user’s level of being pleased or delighted with the product. This, for example, will drive the net promoter score.
When conventions are violated, new learning is required. More often than not, the merits of the new system are irrelevant.
Turning a knob in the clockwise direction increases the effect while anti-clockwise decreases the effect. Blue taps mean cold and red means hot. There are certain expectations that are hard-tuned and aligned with natural conventions while others are learned behaviors. Certainly, earned behavior also creates stickiness. When you uproot a user’s stickiness, you are taking the risk of losing the customer to better user experience offering from the competition.
Hopefully, this article was useful. Tell me what you think on the forum!
by Dasha Gurova | Jul 2, 2019 | Stories
With open source software ubiquitous and irreplaceable, setting up a license compliance and procurement strategy for your business is indispensable. No software engineer I know wants to voluntarily talk about open source compliance but not doing it may lead to a lot of pain. Do you remember the litigations by GPL-violations with D-Link, TomTom and many more in the early 2000s?
It’s better to keep in mind open source license compliance from the early stages of development when creating a product: you want to know where all its parts are coming from and if they are any good. Nobody thinks they will be asked for the bill of material of their software product until they are.
“Open source compliance is the process by which users, integrators, and developers of open source software observe copyright notices and satisfy license obligations for their open source software components.” (The Linux Foundation)
Objectives for open source software (OSS) compliance in companies:
- Protect proprietary IP
- Facilitate the effective use of open source software
- Comply with open source licensing
- Comply with the third-party software supplier/customer obligations
What is a software license?
Put very simply, a software license is a document that states what users are permitted to do with a piece of software. Open source software (OSS) licenses are licenses that the Open Source Initiative (OSI) has reviewed for respecting the Open Source Definition. There are approximately 80 open source licenses (OSI maintains a list and so does the Free Software Foundation although these are called “free software” licenses), split between two larger families:
- So-called “copyleft” licenses (GPLv2 and GPLv3) designed to guarantee users long-term freedoms, make it harder to lock the code in proprietary/non-free applications. The most important clause in these is that if you want to modify the software under copyleft license you have to share the modifications under a compatible license.
- Permissive/BSD-like open source licenses guarantee freedom of using the source code, modifying it and redistribute, including as a proprietary product. (for example MIT, Apache.)
Despite the variety of license, companies sometimes invent new ones, modify them with new clauses and apply them to their products. This creates even more confusion among engineers. If your company is looking to use open source software, tracking and complying with every open source license and hybrids can be a nightmare.
Establish an open source license compliance policy
The goal is to have a full inventory of all the open source components in use and their dependencies. It should be clear that there are no conflicts between licenses, all clauses are met and necessary attributions to the authors are made.
Whether you have an open source project using other open source components, or a proprietary project using open source components, it is important to establish a clear policy regarding OSS compliance. You want to create a solid, repeatable policy to outline what licenses are acceptable for your specific project.
Ways to execute OSS compliance
Manual
A surprising number of companies are still using this approach. Basically, you create a spreadsheet and manually fill it out with components, versions, licenses and analyze it against your policy.
This works out well for smaller projects if they established a compliance policy (list of licenses or clauses acceptable in the company) from the beginning to spare themselves trouble in the future. In this scenario, every developer must review and log a software’s license before introducing the open source component.
The downside of this approach is that as the quantity of OSS components in the project grows, it becomes more difficult to keep track of relationships between licenses (if they all work together or there are conflicts). It is vital to list them as the dependency might have a different license than the actual library you are using.
Semi-Automated OSS Compliance
This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it gets overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.
Of the tools I’ve seen, there seem to be four main approaches used:
- File scanners – usually involve all sorts of heuristics to detect licenses or components that usually would be missed by developers. Usually, these tools offer different formats for the output.
- Code scanners – it is just exactly what it sounds like. You can use them periodically to check for new open source components.
- CI (continuous integration) scanners – these tools integrate into continuous integration or build tools. This will automatically detect all open source components in the code every time you run a build. The idea is to create a unique identifier for each open source component in the build and reference it against a database of existing components. You can also set policies to break the build if a blacklisted license is found.
- Component identification tools – these tools can help you produce SBOM (software bill-of-material), the list of OSS components in your product.
Tools worth checking
Open source and free tools:
Proprietary Tools:
And so many more…
Organizations:
Conclusions
For smaller projects, fully manual tracking might be sufficient to achieve license compliance. For more complex projects, especially the ones built in an agile style with regular releases, automation is better. Whichever way you choose to handle OSS compliance you should not ignore it for the sake of your project and sustaining open source community. Come by our forum to discuss or ask me questions.
