Speckle is an Open Source project, and we are always happy when our Community makes open-source contributions to Speckle. In turn, as part of our work at Speckle, we contribute to other projects. These contributions come in many forms: documentation, bug fixes, entire features, feedback, and a general love for all things open source. We’ll highlight some of these contributions, which validate how rewarding and impactful contributing to Open Source projects can be.
::: tip
"Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program." - Linus Torvalds
:::
Our Open Source Ethos
Speckle stands on the shoulders of many Open Source projects, all of which we are grateful for and wish to contribute more. Open Source is fascinating in enabling countless others to achieve their goals by solving specific problems and helping each other. It is a vast collaborative effort that has transformed industries that have embraced it, each individual contributing to building something more significant than the sum of its parts.
Open Source is a core part of Speckle’s ethos; we benefit from it as our Community submits bug reports, fixes problems, or builds entire Connectors. Let’s break down some of the projects we at Speckle have been contributing to.
Packaging Open Source Software (OSS) for Installation on an Open Source Platform
Any server infrastructure’s essential part is log messages. Speckle’s servers generate many log messages, which we wish to gather together to analyse and understand the behaviour of Speckle. This helps improve performance for forensic investigations after (or during) incidents, guiding future development and providing the data we need to make better decisions.
We export our log messages to Graylog Extended Log Format (GELF) format to an analysis platform, Seq. This latter provides a tool, seq-input-gelf, to ingest GELF and convert the logs to Seq’s native format, as shown in the below diagram.
DataLust, the maintainers of Seq, provide a Helm Chart for deploying both Seq and seq-input-gelf together in a Kubernetes cluster. However, we wish to deploy seq-input-gelf independently of Seq. We could not find a Helm Chart to deploy seq-input-gelf independently of Seq, so we started an open-source project. We hope this Helm Chart will be helpful to others who need to forward logs in GELF from multiple Kubernetes clusters.
::: tip
Kubernetes Cluster: A set of machines, called nodes, that run containerised applications managed by Kubernetes
Helm Chart: A package of pre-configured Kubernetes resources
:::
Helping improve Nuxt and related UnJS projects
Nuxt is a JavaScript/TypeScript web framework allowing developers to rapidly create modern full-stack web applications. The Nuxt framework combines some best-in-class open source projects, such as Vue, to provide the user interface and Nitro & h3, providing a web server to host the application. Many of Speckle’s newer features, such as the new frontend, are built upon these technologies.
As we have been developing upon Nuxt, we have occasionally discovered bugs or missing features and have created several bug reports, bug fixes, and even pull requests to resolve the issues ourselves. This has resulted in a better tech stack for us and everyone else relying on these fairly popular projects.
For example, on the backend side, we’ve introduced proxy handling and route matching changes in the h3 web server. On the frontend side, we’ve brought up bugs regarding data fetching, Nuxt state serialization/deserialization and opaque behaviour regarding component auto-scanning.
Fixing Bugs When No One Else Will
Open-source projects are often the lifeline of many products and services. They’re what keep our systems running and our businesses flowing. However, open source projects can sometimes feel like abandoned playgrounds—swings broken, slides rusted. If you happen to rely on one of these projects, what do you do when you discover a bug that no one is around to fix?
Speckle’s experience with vue-apollo presents a case study in taking the bull by the horns. We depend heavily on this library for enabling smooth interaction with GraphQL APIs in our Vue components. Over time, we started noticing performance bottlenecks and inconsistencies, which led us to investigate.
Vue-apollo is a troublesome library we depend on and appreciate a lot for existing in the first place - a Vue and Apollo Client integration. Apollo Client is the best frontend library for interacting with GraphQL APIs, and if you want to use it in your Vue components, you need vue-apollo.
Upon digging into the code, we found that the library had yet to be actively maintained. While this posed a risk to our technology stack, our values of proactive accountability and quality obsession drove us to solve the issue rather than await a fix.
We treated this as an open invitation to improve upon the existing code. After a thorough analysis, we pinpointed the serious problems, developed patches, and submitted pull requests to the repository. These contributions weren’t just a temporary patch but comprehensive solutions that improved the project's performance and reliability, helping both Speckle and the broader community.
While waiting for our fixes to be reviewed and merged, we used our forked version to continue our development. This illustrated the power of open source: when the traditional route of ‘issue and wait’ wasn't working, we could step up and contribute directly, ensuring that our project and countless others were no longer blocked.
Even when open-source software has issues with its code and lacks active maintainers, anyone from the sidelines can jump in and resolve them. Our commitment to open source mirrors our larger mission of fostering a proactive, accountable, and quality-obsessed community.
::: tip
If a rising tide lifts all boats, contributing to open source is like the tide that lifts entire fleets.
:::
Grasshopper Async Component
Native Grasshopper components GH_Component and GH_TaskCapableComponent will freeze the user interface while solving, which can lead to relatively large user wait times depending on the complexity of the operations.
Our Grasshopper Async Component was born out of the need to perform long-running operations (such as sending and receiving from Speckle) in McNeel’s Grasshopper while still being able to report progress to the user.
This component, Gh_AsyncComponent, enables developers to use asynchronous tasks that can be run in the background and allow them to maintain feedback to the user, including task cancellation, progress reporting, and more.
xUnitRevit
Software vendors sometimes make it very easy to develop plugins for their platform but need help applying proper software engineering practices. This is especially true when dealing with proprietary technologies that can only be accessed while the software is open and running. To solve this problem, we created xUnitRevit, a small WPF-based project to enable Revit plugin developers to test their logic in unit tests and run them directly in Revit.
This allows you to test individual parts of your plugin’s logic and verify they work correctly, including document creation, transactions, etc. You can read the original blog post about it here.
The xUnitRevit and GrasshopperAsync are examples where we have solved problems for ourselves and reshared these so others building software for AEC might benefit. Any improvements we find that can be isolated for reuse save wasted time across the industry so that we can all focus on the mission of improved collaboration and connectivity.
Using SQLite3 Library in SketchUp
SketchUp extensions typically require high compatibility and isolation from other extensions and system libraries. Gem extensions are shared libraries that may have dependencies or conflicts with other gems or the SketchUp environment. This is the main reason SketchUp developers introduced Rubocop for SketchupRequirements/GemInstall.
It doesn’t mean we cannot use external libraries. Still, we must compile these libraries with the correct ruby version and runtimes by wrapping all classes with our plugin namespace simply because every code piece we use in our extension should be in our topmost plugin namespace.
The library is SQLite3, which we use to read and write accounts and object data that pass through on send/receive operations. The way we followed is using the C++ source code of the SQLite3 library by compiling it according to our needs. Any SketchUp Extension developer can fork this project and compile it for themselves by only changing the topmost namespace of the project with their extension namespace.
Open Source and Speckle
Getting started with contributing to Open Source projects can be confusing and intimidating. We would love to hear from you if you would also like to contribute to Open Source. Community contributions make Speckle progress towards a more robust and powerful tool for AEC. Contact us in our Community forum to know what you’d like to build next.
What’s Next?
Join us at SpeckleCon: our virtual online conference, where we will focus on unlocking data to fuel collaboration, automation, and connectivity across all design workflows.
"The future of open-source is data, not code." – Ben Lorica, Chief Data Scientist at O'Reilly Media
Over two days, you’ll participate in talks and workshops with fellow designers, coders, and entrepreneurs. Together, we will explore and build the tools and workflows you need to deliver and create value at scale.
