- Product owners
Every day, developers from around the globe, harness the power of technological transparency to bridge gaps and build communities that are reshaping our world. You’re probably not even aware it’s happening. Don’t be fooled. It is.
Thanks to Open Source technologies, communities are growing in ways no one ever thought possible; everyone, from small startups to industry leaders, is contributing to support massive Open Source projects. Together, great minds collaborate to achieve the unthinkable as they develop world-class technologies in the most efficient of ways.
Standing on the Shoulders of Giants.
Empowering communities to scaffold and build off one another to achieve quality like never before. The unquantifiable amount of sourced projects, rich libraries, and ever growing frameworks, are all a remarkable testament to their commitment and will.
Although these glory days offer endless opportunities, they aren’t without risk. Each and every framework comes with its extensive list of pros and cons. There are numerous pitfalls to avoid and strategies that you can use to prevent from wasting your precious resources, time, and energy.
Given enough eyeballs, all bugs are shallow.
I’ll admit that my team and I have gotten better at this with time. With multiple projects on the go at once, we’ve become accustomed to analyzing, defining, and selecting the best Open Source technologies for each of our clients. These projects have also allowed us to experiment with numerous Open Source frameworks, providing us with valuable insight and predictive analysis methods. Given my appreciation for Open Source technologies, it would be illogical and counterintuitive not to share what I’ve learned thus far, and how the Mirego team tackles this intricate process. In this first post, I’ll explore how to go about choosing the best Open Source technologies for mobile and Web-based projects. I’ll follow up with a second article about those good ol’ Open Source misconceptions and how to avoid falling for them.
Part One: Defining Your Open Source Criteria
So, you’re looking into an Open Source technology and you’re not ready to commit just yet. Commitment-phobes, look no further… our team’s Open Source criteria checklist will help you determine whether you’ve found the right one, or whether you should move on and keep browsing. Now, let’s get to it!
Considering maturity is critical to building any solid stack. How long has this technology been around? With scalability, performance, and sustainability in mind, you’ll want to validate whether the technology has been in use long enough for the core issues to be ironed out. The last thing you need is an unstable version with frequent updates that require complex rewrites.
Are you maximizing the company’s manpower? Will this decision limit the company’s ability to grow and perform in the long run? Not only does optimizing fit and load apply to the framework you’re using, but it also applies to your team. Understanding your team allows you to make strategic decisions that maximize your team’s manpower as the business continues to push forward.
Will this technology affect the development and sustainability of your project? Debt is never a good thing. Decisions you take to ship quickly will ultimately impact your project in the long run. You have to be even more careful when an external dependency is involved because even if it’s not some code you wrote, it becomes “your code” and you’ll have to maintain and support it for as long as the project lives.
Could using a generic alternative widen your scope and broaden your reach? There’s no such thing as a one-size-fits-all solution. Being aware of the specificities surrounding your project (technology, user base, use case, context…) will help guide you through the decision-making process. Who is this technology designed for? Adaptability is also key. Being too specific in regards to use cases may limit your choices.
Will implementing this new technology affect the team’s performance and overall project development? How complex is this technology? Complexity should be weighed strategically with technical scalability and performance in mind. For instance, learning a new framework could be advantageous to any business if it opens the door to new opportunities down the line. However, complexity should never come at the expense of quality and execution.
What problem are we trying to solve? Always, finish with the beginning. Refer to your project’s scope statement to clarify the needs and expectations set for your project. Also, keeping an eye on key milestones and delivery dates will help keep your team focused as you build a product that is supported by an efficient stack and performant core.
Open Source technologies rely on collaborative developers to supplement their libraries and enrich the resources made available to the organizations who adopt them. Each community carries with it a unique culture, structure, and organization. You’ll want to examine the following points before joining:
Size reflects the wealth of knowledge made available. How big is the community? Look for large communities driven by highly motivated developers who encourage and foster open communication as well as collaboration amongst their peers. This is a great indicator as to whether they’ll be approachable and responsive should you experience any issues or require some help along the way.
How active is the community? Not only do activity levels characterize community engagement, but they shed light on the technology’s maturity and momentum as well. Although high activity levels indicate active participation, it may also suggest that a technology is still in its early iterative phases. In contrast, low activity levels may also be cause for concern, suggesting a loss of momentum, which could ultimately stall your development. But, it could also mean that the codebase is rock solid and the project is feature-complete. Investigate any red flags that could affect the long-term sustainability of your core.
Who is involved in developing this technology? Doing a little background check will bring depth to numerous aspects such as, weight, scalability, reliability, sustainability, and more. For example, the presence of bigger players may be synonymous with a larger user base and heavier load. How do the imposed constraints impact the sustainability and development of your project?
Once you’ve analyzed your situation and checked all of these boxes, it’s up to you and your team to evaluate how the chosen Open Source technology will affect any of the factors mentioned above. As you determine the best course of action, I’d advise that you work in close collaboration with your team. After all, open communication is key to building solid teams that collaborate efficiently and cohesively. That’s how we do it at Mirego.
Feel free to give my article a share if you found it valuable and stay tuned for Part Two where I’ll dig into the common Open Source misconceptions.