TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Open Core Development Philosophy

5 posts · Sep 2014 – Jul 2022

What this trail covers

GitLab is evolving its open core development philosophy by open-sourcing eighteen features across various stages of the DevOps lifecycle. This move aims to empower the community, align the business model more accurately with the buyer-based open core model, and make it easier for individual contributors to access a wider range of functionalities. The open-sourced features span Plan, Create, Verify, Package, Release, Configure, and Protect stages, including functionalities like related issues, ex. This post details how enterprises can leverage open source workflow practices like visibility, forking, pull/merge requests, testing, CI, documentation, and issue tracking, often enabled by distributed version control and modern tooling. GitLab's introduction of an 'internal' project visibility level allows employees to reuse code, fork it, and contribute back, keeping code secure while benefiting from open source workflows.

All GitLab trails
  1. Open core is worse than plugins... and that’s why it’s betterThis post introduces and elaborates on the 'Worse is Better' philosophy as applied to GitLab's open core development model. It contrasts this with traditional plugin-based architectures, highlighting the advantages of direct code modification and rapid feedback loops in fostering a more adaptable and ultimately superior product. The author argues that while plugin interfaces are theoretically ideal, they introduce premature abstraction and slow down iteration. GitLab's open core approach, with its 'low fences' rather than 'brick walls,' allows for greater flexibility and faster adaptation to user needs, leading to a more integrated and functional end product.
  2. 18 GitLab features are moving to open sourceThis post announces the open-sourcing of 18 features across 7 DevOps stages (Plan, Create, Verify, Package, Release, Configure, Protect). It details the rationale behind the Buyer-Based Open Core model and the decision to audit and move features to the Core/Free tier. Specific features being open-sourced include: Related issues, Export issues, Issue board focus mode, Service desk, Web Terminal for Web IDE, File syncing to web terminal, Design Management, Code quality reports, Conan, Maven, NPM, and NuGet package managers, Canary deployments, Incremental rollout, Feature flags, Deploy boards, Support for multiple Kubernetes clusters, and Network policies for container network security. The post links to specific GitLab issues for the implementation of these changes and invites community contributions.
  3. OpenCores come to GitLabThis post announces the migration of the OpenCores community and its projects to GitLab. It highlights the benefits of using GitLab for gateware development, including source control, CI/CD features for Continuous Verification (CV), and the overall goal of reducing gateware design cycle time. The post details the nature of gateware and IP cores, the role of OpenCores, and the stewardship by Oliscience. It also touches upon the increasing importance of FPGA and ASIC development and the adoption of DevOps culture in this domain.
  4. 4 Examples of the power of open source analyticsThis post highlights how GitLab's Data Team has embraced an open-source philosophy by making their primary code repository public and MIT licensed. It details a specific instance where an external contributor enhanced the codebase by converting PostgreSQL-specific SQL to Snowflake-compatible format for date metadata generation, which was then merged and is now relied upon. The post also discusses the benefits of this transparency for community engagement and driving industry forward, emphasizing that the analytics code itself is not the competitive advantage, but rather the data and the decisions made from it.
  5. The 7 Most Important Open Source Workflow Practices for EnterprisesThis post introduces the concept of 'inner-sourcing' and details seven key open-source workflow practices (visibility, forking, pull/merge requests, testing, continuous integration, documentation, issue tracker) that enterprises can adopt. It highlights how GitLab's introduction of an 'internal' project visibility level facilitates these practices by allowing employees to discover, fork, and contribute to internal projects, thereby improving collaboration and reducing duplicated effort.