Welcome to our public repository for the CURIOSS Patterns Practice.
Knowledge sharing is at the heart of the CURIOSS community. Our members develop 'patterns' to record how they resolve problems facing Academic OSPOs in university and research institutions.
We categorize the patterns based on the common priorities or challenges identified by members. The categories are listed under the Table of Contents (on the right of the page if you're on a laptop). You can also scroll down the page to review category by category.
A pattern will be listed more than once if it relates to multiple themes.
For more information about patterns in general, scroll down to the About Patterns section below.
Patterns are reusable solutions to common problems within a specific context. Originating from architecture and urban design in the work of Christopher Alexander (see section on Origins), they were later adapted for software engineering, organizational design, and beyond. A pattern captures the essence of a proven solution in a way that can be applied flexibly to different scenarios, providing a shared language for understanding and resolving recurring challenges.
The CURIOSS Patterns Practice is based on the InnerSource Commons Patterns Practice and we would like to thank all those in that community for inspiring us in this effort.
- Context: Describes the situation where the pattern is applicable, including preconditions and constraints.
- Problem: Identifies the core challenge or issue the pattern addresses.
- Solution: Offers a general, adaptable approach to solving the problem.
- Consequences: Discusses the trade-offs and implications of using the pattern.
For CURIOSS Patterns we also include:
- Title: A phrase that helps identify the pattern.
- Theme/Cateogry: To help us categorize our patterns.
- Known Instances: Information about who has used the pattern.
- Contributors: A list of all those who contributed to the creation of the pattern (inside and outside of GitHub).
In some cases, we have even included some personal inspiration from the pattern authors.
- Encourage reuse of proven solutions.
- Foster shared understanding and communication within teams.
- Provide guidance without prescribing rigid processes.
- Enable scalability by breaking complex systems into manageable components.
Patterns are not standalone solutions but are often organized into collections. Practitioners use them as building blocks to address complex problems by combining and adapting multiple patterns. A common workflow includes:
- Identify the Problem: Understand the specific challenge and its context.
- Select Relevant Patterns: Look for patterns that address similar problems or contexts.
- Adapt the Pattern: Tailor the solution to fit the unique aspects of the current situation.
- Implement and Iterate: Apply the solution, observe its impact, and refine as needed.
We hope that those who implement or adapt patterns here will contribute back their learning to help improve the overall practice.
The process of creating patterns involves observation, abstraction, and testing:
- Observation: Identify recurring problems and successful solutions in practice.
- Abstraction: Extract the underlying principles and structure from specific instances.
- Validation: The pattern matures as it is applied the pattern in different contexts. This stage confirms its effectiveness and generalizability.
- Documentation: Use a consistent format to record the pattern, often as a template, making it accessible for others to use. Here is the CURIOSS pattern template.
As CURIOSS and the idea of Academic OSPOs is relatively new, we recognize that the CURIOSS patterns may not yet have significant validation (i.e. may only have been used in one university). We hope to add further known instances over time.
The concept of design patterns originated in the field of architecture. Christopher Alexander, an architect, introduced the idea in his book “A Pattern Language: Towns, Buildings, Construction” published in 1977. Alexander’s work focused on identifying recurring problems in architectural design and proposing solutions that could be reused in different contexts. His patterns were intended to improve the quality of life by creating environments that are functional, aesthetically pleasing, and harmonious.
Alexander’s approach to patterns was revolutionary because it provided a structured method for solving design problems. His patterns were not rigid blueprints but flexible guidelines that could be adapted to specific situations. This adaptability made them highly valuable in architecture and laid the groundwork for their application in other fields.1
Thanks for wanting to contribute. Please take a look at our brief Contributing Guide.
All work here is licensed under a CC-BY 4.0 International License (https://creativecommons.org/licenses/by/4.0/deed.en), by the CURIOSS organizers and contributors.
Footnotes
-
‘History and Evolution of Design Patterns: From Architecture to Software’, Design Patterns. Accessed: Dec. 12, 2024. [Online]. Available: https://softwarepatternslexicon.com ↩