Our platform accelerates word-of-mouth by allowing any product to be shared and discovered in only a few clicks

Cello

Picture this: two identical coffee shops at opposite corners of a quaint little town. The coffee beans? Sourced from the same Colombian farms. The espresso machines? Same exact models. The ambiance? Practically indistinguishable. Yet, one is thriving, and the other is barely scraping by. So, what sets them apart? Imagine walking into the thriving coffee shop. Mr. Anderson, a regular, walks in right behind you. The barista doesn't just know his order—a tall latte with a hint of vanilla—but also that he prefers almond milk, only on Tuesdays, and that his dog Max had surgery last week. After a quick chat, Mr. Anderson walks out, not just with his latte but also with a complimentary dog treat for Max. That's personalization, and it's precisely what SaaS companies must aim for. We are in a new era of customer relationships—the era of personalization. All the Features Look the Same… Features became commonplace, even mundane. They get replicated at a faster and more efficient rate than ever imagined. The very essence of software became democratized, leading to a paradox: the better the functionalities became, the less they seemed to matter. Consider Zoom. With a vast product offering tailored for different customer segments—businesses, individuals, students, and senior IT leaders— Do we think that Zoom will continue leading the market by providing better virtual meeting features? Here we are, drowning in features that look the same. What if the future of SaaS isn't in what the software can do, but instead in how well it knows what you need it to do? Consider the project management tool that recognizes when you're assigning too many tasks in the late hours of Friday evenings. What if, instead of bombarding you with a generic prompt or a 'how-to' guide, it suggests a more efficient delegation strategy for your next week, allowing you to enjoy a well-deserved weekend? The Crucial Nuances Once a company scales beyond the horizon of product-market fit, it starts noticing the subtleties among its customers. -   Some prefer receiving only critical updates, while others bask in the glory of every new feature. -   Some want to explore a product quietly before speaking with a salesperson, while others wish for immediate human interaction. -   Some expect different values from different product lines. -   Support? It's a whole new Pandora’s box. A user might want extensive documentation, while another requires one-on-one hand-holding. Thus, to maximize growth, it becomes clear that personalizing every single step of the customer journey is not just a luxury—it's a necessity. The Instagram Paradigm Instagram and YouTube have aced personalization in content delivery. Your Instagram feed is fundamentally different from your spouse's, offering a tailored universe. But can this paradigm be replicated when it comes to Marketing, Sales, Product, and Support in SaaS? The Path to Personalization and Revenue Growth So, how does one achieve this level of personalization when there are thousands of Mr. Andersons? At Coho AI, we've distilled it into a three-part symphony: First Movement: Data Consolidation and Normalization Firstly, gather all customer data into a robust, layered data model. -   Layer 1: Meta-data like job title, email, etc., often sourced from third parties. -   Layer 2: Relationship details like product tier, internal communication, sitting in your CRM, or user database. -   Layer 3: Product usage patterns, which require meticulous data collection and translation of raw UI, backend events, and user state. Second Movement: Auto-Segmentation and Actionable Insights Once data is consolidated and normalized, it's time for auto-segmentation. This process continuously evolves, refactoring new data points and allowing faster tailoring of customer experiences. Analyzing segmentations will allow us to learn based on the context of the user, identify leading indicators for desired outcomes, and construct actionable insights on every single user to achieve our goals. This is where insight turns into strategy. Third Movement: Real-Time Automation and Engagement Finally, let's bring in the cellos and violins—emails, pop-ups, feature flags, and a fully integrated subscription management system—all orchestrated in real-time, aimed at engaging the customer when it counts the most. The Standing Ovation Imagine a world where every interaction you have with a SaaS company feels like Mr. Andersons's experience at his favorite coffee shop. That's the kind of responsive, deeply personalized experience that not only fosters loyalty but also turns every user into an advocate. We are past the age of features. The new frontier lies in mastering the symphony of personalization, where every note is tailored to resonate with you—be it in customer support, product experience, or sales interaction. Undertaking this may seem overwhelming at first, but it genuinely doesn't have to be. The real challenge? Making the commitment to this shift and aspiring for your company to be the thriving coffee shop everyone raves about. As for the intricate details and next steps? Coho AI has got you covered, managing the heavy lifting with finesse.

Hello Mr. Anderson: Orchestrating Personalization in the World of SaaS

Head and Shoulders

The Offshore Pirate

Saboteur of Space

How to Make a Cost-effective Flexible Robotic Solution for Low-volume Production

Why Design a Scalable Factory? A “conventional automotive” production line has a requirement to produce volumes in the hundreds of thousands per annum which results in an industry average cycle time requirement of 60 seconds, resulting in a product from the production line every minute. This means that all assembly steps of a certain product must be completed within the cycle time. In turn, this usually leads to breaking up the production process into “stations” with one or more production steps performed at each. The number of steps per station is limited by the cycle time and the duration of the individual step. The system is designed so that each station is sufficiently utilized while still achieving the cycle time. If there is an assembly step that can not be completed in the required cycle time, the stations must be duplicated and run in parallel to achieve the target production output. Time constraint is not the only limitation for the number of steps that can be performed per station. In some cases, the complexity (process or equipment) of a specific step in the assembly process may result in the station performing only the assembly step even though the processing time is well below the cycle time. Problems appear when we are asked to provide a lower-volume production system (longer cycle time per product) or a system that can scale up and down by stages or on demand, or, even worse, a system that can produce various products simultaneously and remain efficient. It means such a production system has to be capable of adapting to different cycle times and different sequences (number, types of operations) of production processes. To meet the demands of “low” volume, easily scalable automated production of complex assemblies with low CapEx and in a small footprint factory, we, the Robofacturin team in Arrival UK, had to come up with a new flexible, scalable architecture, which allows us to process a high number of assembly steps using different joining technologies. Mathematically, in the limit, such a system must consist of universal resources (cells) in many-to-many relationships (matrix). On the one side, each such cell (resource) must be capable of performing all (the more, the better) types of operations. On the other side,  every product for assembling (the input to the system) must consist of the same (the fewer different types, the better) parts or granules (pixels). Of course, this is the description of an ideal, unattainable system. We can only try to make a real system closer to the ideal. But it is impossible for traditional factories, in principle, by design - there is a linear sequence of operations and cells, most of which are unique, etc. We found that the best concept from the other industry is a Datacenter that consists of unified blade servers and which can process different types of load (inputs) balancing between resources (servers). This concept requires: Universal multi-task cell (blade server for our "Datacenter") Flexible transportation system (databus for "Datacenter") Design of products maximum closer to the ideal pixel structure (data for our "Datacenter") The is the subject of this article. We will mention the to explain basic principles, but this topic, along with the one, is the subject of separate articles. It is worth mentioning that the third topic, in practice, means finding a design that is most suitable/compatible with such kind of factory. We can call it Design-to-Robofacturing. first point second third Technology Cell (“blade server”) To fulfil the scalable factory production requirements, the production system must be able to perform many diverse operations in one station to assemble a product. These operations can vary from part pick and place operations to applications of adhesives, sealants, and different types of fasteners. A high number of unique parts that the assembled product consists of also present a requirement for the station in the production system to be able to accommodate a large number of tools. In response to these requirements, we designed a robotic cell that accommodates multiple joining technologies and can process any assembly step of a produced product. We named it a Technology Cell or Smart Cell. A is a product and process-agnostic robotic cell that can be used for different processes and products without changing its Core Blueprint. The is a blueprint of the cell that does not include any equipment that would be specific to a certain product or process. Technology cell Core Blueprint For a Technology Cell to be capable of performing the operations required to assemble a product, a Core Blueprint must be equipped with technologies which give the Technology Cell ability to perform assembly operations for a particular product . At this point, the cell becomes technology specific (eg. bolting, gluing) but remains product agnostic. This means it can assemble any product that fits its working volume and is compatible with joining technologies available in the cell. (blue and green objects in the 2nd image below) A Technology cell can also be equipped with another layer of equipment which can be more product or process focused. This additional layer does not hinder the original capabilities of the technology cell, but it extends them to more unique processes that are only needed in specific steps. An example of such a cell would be the Marriage and Glazing features, where a system for the marriage of drivetrain systems and battery pack with the vehicle is permanently located in the cell . (purple objects in the 3rd image above) Creating a Chipset: Building blocks, Applications and Tooling A flexible factory must be capable of dealing with many different products, systems and specific requirements for production: vehicles (from a small car up to a bus), composite panels, small electronic components, battery packs, etc. The nature of the products can differ in many ways: size, complexity (part count, system count), manufacturing method, production volumes, and special environmental requirements. A scalable factory should not only be able to be deployed rapidly but also react to requirement changes quickly. This means that the design process of the factory should be streamlined as much as possible while still allowing for creativity and innovation. To achieve this, we created a modular method for the design of production systems. The method defines requirements for the design of components that form a manufacturing system (eg. robotic cell). As these components have different functionality, they are split into three categories: Building blocks, Applications and Tooling. Building blocks are components that form the lowest of the manufacturing systems and are technology agnostic. They don't have any value-added manufacturing abilities but provide a framework to which we can apply different technologies to give a system process capability. This framework is called a “Core blueprint” and is the first layer of the solution to which the process capability is added. Typical members of this group are all safety-related, geo pallet lifters, geo fixture positioning systems, and robot assemblies. The image shows a Core Configuration of the Production system consisting of Building Blocks only. At this point, the cell is able to accept the layer of applications. Applications are technologies that give a production system process capability. Examples of such applications are adhesive applications, bolting, picking and placing, trimming, handling, machining, scanning, etc. These applications are product-independent, meaning they don't have any features that are specifically designed to accommodate a unique product. The image shows an (applications) layer being added to the Core blueprint of a production system. At this point, the system becomes . At this point, the cell can accept the Tooling layover. Application technology-oriented is a group of components that form a production system that is unique to a specific product. Examples of such components are part grippers, fixtures, product transport pallets, and moulds. As they are an extension of building blocks and applications, they must share the same design architecture that allows us seamless integration. The tooling blocks can be split into two major categories. The mobile product tooling, which flows through the production via autonomous mobile robots and fixed tooling, can be permanently located in a production system to extend its capabilities for a specific process (eg. pallet exchange).  It’s at this point that the production system has a full production capability. Tooling Each Building block, Application or Tooling has everything required to be “plugged in” to a production system from a hardware and software point of view. At the hardware level, we can imagine this as a standardized connector with power and communication terminals that allow a building block, application or tooling to be seamlessly plugged into a production system. The architect of the software level allows the control system to recognize and control each of these groups via the manufacturing execution system. Integrating a building block, application, or tool can be seen as a standard socket and plug connection. The modularity approach sets a design standard that ensures every element can be plugged into any system design. This allows us to quickly configure any production solution by reusing the objects already in our library and assembling them in a new configuration. As visible from the schematics configurations below, there is a large number of shared objects between very different manufacturing systems (robotic cells). If there is a requirement for a significant number of less complex assemblies to be produced in the factory, it may be sensible to create a few simpler, lower CAPEX and footprint cells with architecture better suited to these types of assemblies. Where a manufactured product is more complex, we can configure a system that will be better suited for the complex use case. Transportation System: Autonomous Mobile Robotics The scalable factory operates with a small footprint and a small number of assembly stations that can process a high number of assembly operations. Therefore we had to come up with a method to be able to feed each of these stations with a large number of tools and parts. In a more conventional production system where each station only performs a small number of operations and uses a small number of tools (grippers or joining equipment), these can be permanently located in the station (robot cell) within reach of the robot that handles it. The reach of the robots is in some cases, enhanced using an external linear axis. However, this still does not satisfy business requirements for the number of tools that must be processed in one station (robot cell)  to meet the requirements of the factory. A monolithic production line only has a small number of steps performed at each station. Therefore the number of tools for each station is relatively low. With fewer assembly stations, significantly more tools must be fed to each station. To meet this requirement, our Mobile robotics team developed an autonomous mobile robot called (wheeled mobility) that can deliver any tool to any assembly station.  The robot does not require any modifications to the facility in which it operates. WeMo uses lidars and cameras for navigating through the facility and precise positioning at the locations where its payload has to be precisely dropped off, picked up, or it’s plugging itself into a charging station. WeMo has an integrated lifting capability which allows it to pick up and drop off objects where required. They can operate as an autonomous, independent unit or can connect into “clusters” and work synchronously to move larger and heavier objects when required. WeMo To achieve the ultimate flexibility, we located the tools away from the cells in the logistics area where the operators load the parts into the robot tooling. When the part is required at the assembly station, the manufacturing execution system orders a mobile robot to collect the tool or a part from the logistics area and deliver it to the robot at a precise time without interfering or slowing down the production process. In the case of the Technology cell, the Tools (T) can be delivered to the 4 outboard locations where they can be picked up by a robot. The image above shows only one logistics area where all the tools are located. However, this doesn’t have to be the case. With the use of autonomous robots for the execution of the logistics system, we can arrange the area where tools are located in as many locations as we like. This allows us to optimize the layout for logistics efficiency, environmental requirements of the parts (batteries), and their need for lift assistance. The AMRs are not only tasked with the tool and part delivery to and from the build stations, but also with moving the assembled product between them. The ability of AMRs to autonomously navigate through the facility allows us to be flexible with the positioning of the assembly stations and arrange them in a configuration that meets the factory production requirements. The image shows a cluster of four technology cells that can be used as a production system with two parallel processes with two assembly stations (cell) each or a single four-station production system. Scalable factories are deployed in existing facilities. Therefore, we have to be able to react to any configuration (shape) of the building. With the use of AMRs,  we have more flexibility to utilise the available floor space. The image above shows the cluster of four Technology cells configured in a four station production process. Technology cells are positioned in a configuration that suits the shape of the facility (black outline). Another benefit of not having assembly stations connected via a rigid transport system (eg. conveyor) is that we can be flexible with our production plan. We can feed different products to the same production stations in any order. The image below shows three different routes through the same production system. The black line makes use of all four stations, the green line only utilizes one assembly station, and the blue line utilizes two assembly stations. This allows us to produce different products in the same production line in parallel without any changes being made to the assembly stations. If one cell becomes un-operational, we can reroute the production to a different cell and still operate without stoppage, but at reduced throughput. This is how our Bicseter smart, scalable factory operates, where we produce subassemblies and the main vehicle assembly using the same Technology cells. Software Creation and Deployment Software that runs the factory assembly process is generated autonomously by different internally developed software packages that streamline the process of generating an assembly sequence code that drives each automated action of the production system. The generation process starts with the generation of the Assembly sequence, which is generated from the mBOM of the product. The sequence is then processed by a motion planner and scheduler, which generates all robot trajectories as a sequential flow of operations. The final piece of the puzzle is the Cell operating system which orchestrates all events that are happening in the production process and collects data on the status and quality of the process. The sequence code generation process starts in the Assembly sequence generator software package. To automatically generate an assembly sequence, an mBOM of a manufactured product is uploaded to the generator. Based on the components of the mBOM, the Assembly sequence generator assigns all logistics and assembly operations to each component in the mBOM. Based on the joint/fastener type that is part of the mBOM, the generator assigns the correct joining method and resource to each step in the assembly. The outputted assembly sequence code is then enriched with information about resources that will be tasked with the execution of the assembly process (resources: Cell, robot, Screwdriver, AMR, Gripper…). The final output of the Assembly process generator is a BoP (bill of the process) MetaGraph. The image above shows a section of the BoP MetaGraph. Each step of the process includes information about the process type and all resources that are part of the processing step. At this point, we don't have any actual process code but rather an instruction that the next software package can interpret in the generation process. The generation of BoP in today's industry is still a manual process, usually done by process engineers in a spreadsheet format with supporting visuals for the PLC and Robotics engineers. As with any manual processes, this is prone to mistakes by engineers as it is very labor-intensive. The scheduler and motion planner package have been developed to read the instructions generated by the Assembly sequence generator and, based on its instructions, generate the robot trajectories based on the virtual twin of the resources that participate in a given assembly step (cell, robot, gripper, part, adhesive model). Any CV (computer vision) algorithms are also added to the package at this point. The instructions package with this additional layer is then handed over to the next system, CellOS. The (CellOS) is the system that orchestrates all actions in the production system. The generated Sequential Function Chart and Robot trajectories are processed in the Flow processor and executed. All sequence control logistic is executed via soft PLC. The only system running locally at the production system is a Safety logic of the production stations which the local safety PLC controls to meet the machine safety requirements. cell operating system The assembly sequence is not hard-coded into a local  PLC but it’s rather streamed through the soft PLC, which gives us the flexibility to change the order of operations, build stations or update process parameters without redeploying PLC code. Each building block, application, and tool also have its virtual twin so the software deployment scenarios can be validated before they are deployed. The software of each building block, application or tool is developed alongside their hardware to allow for seamless integration into the system. Therefore each building block and application, and the tool has its associated software block, which allows the Cell operating system to control them (trigger any actions), collect messages, faults, and telemetric data, as well as deploy any process parameters (eg. torque, stroke, angle). This unlocks the ability to be flexible and agile with the implementation of any process or parameter changes. The schematics show the process from the product mBOM, which is being processed in an Assembly sequence generator into a BoP, enriched with motion and process parameters and deployed to CellOS. Once a scenario (assembly process) is deployed to CellOS, there are no further deployments needed unless there is a need for an update of the process. CellOS talks to each element of a production system (Roboti cell) and cell safety individually. Summary As a result, by following the same evolution that transformed a mainframe into a PC, we can significantly decrease the complexity of the architecture of an assembling factory and achieve new characteristics without losing efficiency resulting in: scalability product agnostic smaller footprint simpler design less CapEx But the most important benefit is that new architecture, by design, allows us to implement and use the power of Artificial intelligence software. This can make our factory smart.

Architecture Design of a Smart, Scalable, AI-driven Robotic Production Factory

Free as in Freedom, by Sam Williams, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . A BRIEF JOURNEY THROUGH HACKER HELL The lead image of this article was generated via HackerNoon's AI Stable Diffusion model using the prompt 'a fiery hell filled with computers'. A BRIEF JOURNEY THROUGH HACKER HELL Richard Stallman stares, unblinking, through the windshield of a rental car, waiting for the light to change as we make our way through downtown Kihei. The two of us are headed to the nearby town of Pa'ia, where we are scheduled to meet up with some software programmers and their wives for dinner in about an hour or so. It's about two hours after Stallman's speech at the Maui High Performance Center, and Kihei, a town that seemed so inviting before the speech, now seems profoundly uncooperative. Like most beach cities, Kihei is a one-dimensional exercise in suburban sprawl. Driving down its main drag, with its endless succession of burger stands, realty agencies, and bikini shops, it's hard not to feel like a steel-coated morsel passing through the alimentary canal of a giant commercial tapeworm. The feeling is exacerbated by the lack of side roads. With nowhere to go but forward, traffic moves in spring-like lurches. 200 yards ahead, a light turns green. By the time we are moving, the light is yellow again. For Stallman, a lifetime resident of the east coast, the prospect of spending the better part of a sunny Hawaiian afternoon trapped in slow traffic is enough to trigger an embolism. Even worse is the knowledge that, with just a few quick right turns a quarter mile back, this whole situation easily could have been avoided. Unfortunately, we are at the mercy of the driver ahead of us, a programmer from the lab who knows the way and who has decided to take us to Pa'ia via the scenic route instead of via the nearby Pilani Highway. "This is terrible," says Stallman between frustrated sighs. "Why didn't we take the other route?" Again, the light a quarter mile ahead of us turns green. Again, we creep forward a few more car lengths. This process continues for another 10 minutes, until we finally reach a major crossroad promising access to the adjacent highway. The driver ahead of us ignores it and continues through the intersection. "Why isn't he turning?" moans Stallman, throwing up his hands in frustration. "Can you believe this?" I decide not to answer either. I find the fact that I am sitting in a car with Stallman in the driver seat, in Maui no less, unbelievable enough. Until two hours ago, I didn't even know Stallman knew how to drive. Now, listening to Yo-Yo Ma's cello playing the mournful bass notes of "Appalachian Journey" on the car stereo and watching the sunset pass by on our left, I do my best to fade into the upholstery. When the next opportunity to turn finally comes up, Stallman hits his right turn signal in an attempt to cue the driver ahead of us. No such luck. Once again, we creep slowly through the intersection, coming to a stop a good 200 yards before the next light. By now, Stallman is livid. "It's like he's deliberately ignoring us," he says, gesturing and pantomiming like an air craft carrier landing-signals officer in a futile attempt to catch our guide's eye. The guide appears unfazed, and for the next five minutes all we see is a small portion of his head in the rearview mirror. I look out Stallman's window. Nearby Kahoolawe and Lanai Islands provide an ideal frame for the setting sun. It's a breathtaking view, the kind that makes moments like this a bit more bearable if you're a Hawaiian native, I suppose. I try to direct Stallman's attention to it, but Stallman, by now obsessed by the inattentiveness of the driver ahead of us, blows me off. When the driver passes through another green light, completely ignoring a "Pilani Highway Next Right," I grit my teeth. I remember an early warning relayed to me by BSD programmer Keith Bostic. "Stallman does not suffer fools gladly," Bostic warned me. "If somebody says or does something stupid, he'll look them in the eye and say, `That's stupid.'" Looking at the oblivious driver ahead of us, I realize that it's the stupidity, not the inconvenience, that's killing Stallman right now. "It's as if he picked this route with absolutely no thought on how to get there efficiently," Stallman says. The word "efficiently" hangs in the air like a bad odor. Few things irritate the hacker mind more than inefficiency. It was the inefficiency of checking the Xerox laser printer two or three times a day that triggered Stallman's initial inquiry into the printer source code. It was the inefficiency of rewriting software tools hijacked by commercial software vendors that led Stallman to battle Symbolics and to launch the GNU Project. If, as Jean Paul Sartre once opined, hell is other people, hacker hell is duplicating other people's stupid mistakes, and it's no exaggeration to say that Stallman's entire life has been an attempt to save mankind from these fiery depths. This hell metaphor becomes all the more apparent as we take in the slowly passing scenery. With its multitude of shops, parking lots, and poorly timed street lights, Kihei seems less like a city and more like a poorly designed software program writ large. Instead of rerouting traffic and distributing vehicles through side streets and expressways, city planners have elected to run everything through a single main drag. From a hacker perspective, sitting in a car amidst all this mess is like listening to a CD rendition of nails on a chalkboard at full volume. "Imperfect systems infuriate hackers," observes Steven Levy, another warning I should have listened to before climbing into the car with Stallman. "This is one reason why hackers generally hate driving cars-the system of randomly programmed red lights and oddly laid out one-way streets causes delays which are so goddamn unnecessary [Levy's emphasis] that the impulse is to rearrange signs, open up traffic-light control boxes . . . redesign the entire system."See Steven Levy, Hackers (Penguin USA [paperback], 1984): 40. More frustrating, however, is the duplicity of our trusted guide. Instead of searching out a clever shortcut-as any true hacker would do on instinct-the driver ahead of us has instead chosen to play along with the city planners' game. Like Virgil in Dante's Inferno, our guide is determined to give us the full guided tour of this hacker hell whether we want it or not. Before I can make this observation to Stallman, the driver finally hits his right turn signal. Stallman's hunched shoulders relax slightly, and for a moment the air of tension within the car dissipates. The tension comes back, however, as the driver in front of us slows down. "Construction Ahead" signs line both sides of the street, and even though the Pilani Highway lies less than a quarter mile off in the distance, the two-lane road between us and the highway is blocked by a dormant bulldozer and two large mounds of dirt. It takes Stallman a few seconds to register what's going on as our guide begins executing a clumsy five-point U-turn in front of us. When he catches a glimpse of the bulldozer and the "No Through Access" signs just beyond, Stallman finally boils over. "Why, why, why?" he whines, throwing his head back. "You should have known the road was blocked. You should have known this way wouldn't work. You did this deliberately." The driver finishes the turn and passes us on the way back toward the main drag. As he does so, he shakes his head and gives us an apologetic shrug. Coupled with a toothy grin, the driver's gesture reveals a touch of mainlander frustration but is tempered with a protective dose of islander fatalism. Coming through the sealed windows of our rental car, it spells out a succinct message: "Hey, it's Maui; what are you gonna do?" Stallman can take it no longer. "Don't you fucking smile!" he shouts, fogging up the glass as he does so. "It's your fucking fault. This all could have been so much easier if we had just done it my way." Stallman accents the words "my way" by gripping the steering wheel and pulling himself towards it twice. The image of Stallman's lurching frame is like that of a child throwing a temper tantrum in a car seat, an image further underlined by the tone of Stallman's voice. Halfway between anger and anguish, Stallman seems to be on the verge of tears. Fortunately, the tears do not arrive. Like a summer cloudburst, the tantrum ends almost as soon as it begins. After a few whiny gasps, Stallman shifts the car into reverse and begins executing his own U-turn. By the time we are back on the main drag, his face is as impassive as it was when we left the hotel 30 minutes earlier. It takes less than five minutes to reach the next cross-street. This one offers easy highway access, and within seconds, we are soon speeding off toward Pa'ia at a relaxing rate of speed. The sun that once loomed bright and yellow over Stallman's left shoulder is now burning a cool orange-red in our rearview mirror. It lends its color to the gauntlet wili wili trees flying past us on both sides of the highway. For the next 20 minutes, the only sound in our vehicle, aside from the ambient hum of the car's engine and tires, is the sound of a cello and a violin trio playing the mournful strains of an Appalachian folk tune. Endnote About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Sam Williams (2004). Free as in Freedom: Richard Stallman's Crusade for Free Software. Urbana, Illinois: Project Gutenberg. Retrieved October 2022, from https://www.gutenberg.org/cache/epub/5768/pg5768.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html.

CELLO

cello.so

-- employees

Since n.d.

COMPANY RANKING

CELLO

EVERGREEN INDEX #2046

Representing this company? Click here to claim and customize this page!

Cello WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

CELLO

cello.so

-- employees

Since n.d.

COMPANY RANKING

CELLO

EVERGREEN INDEX #2046

RELATED COMPANIESRANK

STORIES ABOUT CELLO

Representing this company? Click here to claim and customize this page!

Cello WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!