Category: Uncategorized
Scaling Consistency: How GForge Project Templates Simplify Setup and Workflow
Editor’s note (Nov 2025): This article was originally published in 2012 and has been updated to reflect how Project Templates continue to scale collaboration and workflow automation in GForge today.
A Smarter Start for Every Project
When your organization runs many projects in GForge, each with slightly different needs, setup time can add up fast.
Project Templates solve that problem by letting you pre-configure everything once — and reuse it endlessly.
A template defines which GForge features are enabled, sets up default Roles with the right access, and pre-loads Trackers, fields, and workflows that match how your teams actually work.
Instead of spending hours deciding what to enable, who can do what, and how tickets flow, you can start new projects in minutes — already aligned with your organization’s standards.
Built for Flexibility, Not Just Developers
GForge has always supported software teams, but templates aren’t limited to code projects.
They’re just as useful for IT operations, support desks, managed-services teams — even non-technical groups like sales or marketing.
For example, your Product Development tracker might use detailed fields and a multi-step review workflow, while a Support tracker stays lightweight for fast ticket resolution.
Both can live inside one template, so every new project inherits the right structure without manual re-configuration.
Save Brainpower for the Work That Matters
Anyone who’s ever built a custom tracker from scratch knows the mental load: deciding which fields are required, defining statuses, and writing workflows that fit reality.
Templates capture all that thinking once — then let you replicate it instantly.
Each template can include:
- Enabled features (repositories, discussions, document management, etc.)
- Predefined roles and permissions
- Multiple Trackers with unique fields, workflows, and ticket types
- Default notification settings and integrations
Whether you’re managing a single DevOps pipeline or a full enterprise portfolio, templates enforce consistency without limiting flexibility.
Consistency That Scales
Organizations evolve — new teams, new workflows, new compliance rules.
With GForge Project Templates, you can update one source of truth instead of chasing changes across dozens of projects.
We explored how chasing short-term simplicity often leads to long-term tool sprawl in Why Do We Keep Choosing Complexity?
Want to add a new review step to your bug tracker or update access for contractors?
Modify the template once; new projects will inherit those changes automatically.
That’s governance without friction — the balance modern DevOps teams strive for.
From IT Consolidation to Sales Pipelines
GForge templates have even powered complex, non-software initiatives.
One customer used them to manage a multi-department IT consolidation effort — merging email, file, and security systems across agencies.
Another internal team at GForge uses templates to track and manage the sales funnel, proving the same structure works well beyond code.
Any process that involves collaboration, documentation, and accountability can benefit from GForge’s project-template foundation.
Integrated Governance, Simple Onboarding
Because GForge is an all-in-one DevOps & collaboration platform, every template shares the same data model across planning, code, and communication.
That means less integration debt, fewer manual bridges between tools, and faster onboarding for new team members.
It’s the same principle we discussed in RAG AI Isn’t the Answer – By Itself—integration only delivers real value when it’s built into the foundation, not bolted on later.
Each new project spun from a template immediately “knows”:
- What features are active
- How tickets move through their lifecycle
- Who owns which responsibilities
It’s the difference between chaos and clarity.
Available Everywhere
Project Templates are available to all GForge users, whether you’re running on-prem or using GForge SaaS.
They’re included out of the box — no plugins, no add-ons, no extra licensing.
Try It for Yourself
Ready to see how GForge Project Templates can save hours of setup time and keep your workflows consistent? Get started with GForge.
Health Checks: Tasks
This category looks at Tracker Item volume, status, and history.
Note: Because a Project can contain multiple Trackers (for, e.g., Development Tasks, Customer Support, Server List, and whatever else you need), each check can generate multiple fail or warning messages.
Long-Running Tasks
Definition: The number of tasks that have been open longer than 90 days, with some activity in the past seven days.
What it means: Tasks that linger for weeks or months clog your Standup, Burndown, and planning process. These tasks can also be a quiet drain on team productivity – making slow progress on a task requires way more task-switching than small, focused ones.
How to fix? Look at each long-running task, and ask these questions:
- Is this still worth doing? Close it if it’s not valuable.
- Is the task too vague? Clarifying the goal can make it easier to reach.
- Is the task too broad? Create sub-tasks that can go faster.
Recycled Tasks
Definition: The number of tasks that are currently open, but have been closed more than twice in the past.
What it means: Much like Long-Running Tasks, Recycled Tasks get in the way of good planning and tracking. They’re usually re-opened unexpectedly, usually because “done” is poorly-defined or regularly gets “un-done” somehow.
How to fix? Much like Long-Running Tasks, look at each Recycled Task and see if it should be refined in scope or killed permanently. Some tasks that keep coming back have an underlying technical or business-process cause – attack that instead of just changing the band-aid over and over again.
Stale Tasks
Definition: Tasks that are currently open and assigned or in a Sprint, but with no activity in the past 30 days.
What it means: Assigning a task or adding it to a Sprint represents a commitment to completing that Task. Tasks that sit for weeks with no progress are taking up attention and Story Points from other priorities.
How to fix? For each Stale Task, do one of the following:
- Bump the priority
- Re-assign to someone with bandwidth
- Un-assign, and come back to it later
Health Checks: Commits
This category of health checks focuses on the code you check into your GForge Next project, how it relates to task management, team and file sizes.
Commits Per Tracker Item
Definition: The number of separate commits associated to each Tracker Item in your project. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: Having too many commits makes it harder to understand the associated Tracker Item’s history later on. It can also skew Sprint, Burndown, and Release metrics to look bigger or smaller than they really are.
How to fix? Although you can add or remove associations between a commit and a Tracker Item, it’s better to look forward than try to change history. When planning a Sprint or Release, consider the size of each Tracker Item, and break them down into smaller tasks that might affect fewer files, or involve fewer iterations for each TI.
Commits with Tracker Items
Definition: The percentage of commits in the last 90 days that are associated (or not) to a Tracker Item. Also checks for commits that are tied to more than on TI.
What it means: Pushing commits without an associated task is an easy way to mess up your code base over time. It’s also bad for team collaboration and Sprint and/or Release tracking.
How to fix? To fix existing commits, you can create Tracker Items, and associate them using the SCM Commits listing. Click a commit and use the “Tracker Item Associations” section at the bottom of the commit details view.
You can (and should) also fix the process for pushing commits to your project:
- Go to the Project Admin SCM tab, and choose “Require” for the “Associate Tracker Items” option.
- You might also check the “Restrict Tracker Item Associations” setting, depending on whether you want to allow associations between commits in this project and Tracker Items from other projects.
- Usually, this setting should be “Yes” to keep it to the current project.
Committers
Definition: The number of users with commits in the last 90 days, and the proportion of all commits made by each user.
What it means: For smaller projects (with only one or two contributors) this check won’t mean much. For full-sized Agile teams (4-5 contributors) or larger, traditional teams (10 or more contributors), this check can help you understand if work is balanced properly between team members.
How to fix? If you’re not using Tracker Items (and requiring that commits tie to them), then you should start right away. Having a specific task should be required in order to make code changes anyway, and an official task list lets the Product Owner, Scrum Master, or even the team itself to balance tasks among contributors by size, functional area and dependencies. Proper task balancing will lead to balanced commits from the team.
Files Per Commit
Definition: The number of files changed (or added, or removed) by each commit. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: In general, commits should touch less than ten files. Large commits (many files and/or many lines of code) are harder to review, harder to understand later, and more likely to cause merge conflicts with other commits.
How to fix? This is another one where what’s done is done. Going forward, make sure that the team is doing proper analysis on task sizes during planning, and on the changes to be made when working each task. If a specific task requires changing many files, try to find a way to iterate on it, changing a few files in one commit, reviewing/merging that commit, then moving on to the next set of files.
Of course, sometimes you’ll just need to bite the bullet – a breaking change in a dependency/library, an urgent security fix, etc. But those hefty commits should be the exception and not the rule.
GForge How-To: Project Admin SCM Settings
Hello and welcome to another GForge How-To. In this series, we teach you tips and tricks to help you maximize your experience with GForge. This time, we’re talking about the Project Admin SCM page, and the settings available there.
The settings on this page are as follows:
Access Method toggles between accessing your SCM over SSH or HTTPS; SSH is the default.
Git LFS support enables and disables Git LFS support.
Code search indexes the code in your promotion model branches for searching. Code tagging indexes the project’s code to tag related tracker items and user commits.
Enable Anonymous Read allows SCM to be read by anyone, including anonymous users.
Associate Tracker Items has three choices: you can keep commits unattached to tickets, attach them when you want, or require that every commit associates to a ticket.
Restrict Tracker Item Associations requires commit ticket IDs to reference a ticket in the project.
Commit Notifications sends an email to everyone monitoring the SCM repo when someone commits.
Validate Committers ensures that each commit is pushed by an authenticated user.
Validate Assignment automatically assigns a specified ticket to a committer.
Access Text shows any text you type in on the main SCM repo page.
Browse Text shows the text you type on the SCM Browse page.
As you can see, the SCM settings available to project admins can help in customizing and correcting GForge to fit any project’s needs. If you have any questions or feedback about the Project Admin SCM page, you can send us a message here. Make sure to check your inbox for more GForge How-To’s in the future!
Register a Free AccountBig Changes Ahead for GForge in 2020
With 2020 well underway we are hard at work on a bunch of new features that will take your collaboration to the next level. Before we cover what’s in store, be sure to checkout a recap of the “Top 8 GForge Features from 2019”
OAuth Support – Not only will GForge support OAuth, over time we will include support services like Google, ADFS and GitHub.
Conferencing Support – GForge will be looking to add support to conferencing solutions like Zoom.us and WebEx allowing you to launch meetings right from within GForge.
Auto Tagging – There’s a lot of information in a commit. In 2020 GForge will harvest information from commits to provide better analytics. For example, a commit including Java, Javascript and SQL changes will add tags with those technologies to both the project and the author. Similarly, GForge will tag individual tickets in the same manner.
Git Improvements – GForge will be adding Git Large File Support (LFS) this year allowing individual files of up to 2GB to be included as part of pushes.
GitHub Migration – GForge will allow you to import projects from GitHub into GForge which will migrate the Git repository and GitHub Issues.
Workflow Improvements – GForge will add webhook support to ticket workflows allowing for deeper integration. Additionally GForge will include support to lock tickets as part of the existing workflows.
Document Thumbnails – Anywhere you add documents in GForge including tickets, Docman, etc GForge will generate thumbnail images you can preview before deciding if you want to download them.
GForge v19.2 Released!
We’re happy to announce the immediate availability of GForge v19.2. This release includes three dozen new features and a number of bug fixes.
Getting Started with GForgeNext
Highlights in GForge v19.2
Dark Mode – GForge is joining the Dark Mode fray!
Project Groups – Project leads can now create groups of users and assign them a project role. Prior to this release only GForge admins could create groups.
Service Desk – With the addition of Project Groups, GForge can now be used to provide service desk functionality.
Improved Analytics – We’ve been listening and now we delivered. GForge now includes better analytics for better managing your projects and overall project portfolio.
Automated Release Notes – This version of GForge provides improved release management. Now when you complete a release you can, with the click of a button, generate release notes.
Better Navigation – While we’ve received a lot of positive feedback on getting around in GForge, we’ve answered calls to improve navigation.
The v19.2 ChangeLog will help you understand the changes you can expect.
Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.
Why Does Collaboration Software Suck?
Let’s face it, the collaboration space has no shortage of options. Today’s solutions come in different flavors of SaaS, on-premises or hybrid, all promising you that a few mouse clicks will have you collaborating better. The one attribute most of them have in common is they suck. In fact, many of these solutions actually make collaboration worse. To help you navigate your options, let’s lift the hood and explore many of the common problems with today’s collaboration solutions.
- You Get Pieces & Parts
- Too Small or Too Big, Won’t Scale
- Who’s Working for Whom?
- Comments <> Collaboration
- They’re Expensive
- Golden Handcuffs
You Get Pieces & Parts
Let’s face it, as a business grows so do your needs. This transition happens slowly and before you know it you look down to discover you have lots of little solutions each itching a single scratch in helping you collaborate better. Worse yet, navigating between those tools is often painful. In the best case the integration features adds even more buttons to an already complicated user interface. In the worst case you will have to manage a bunch of bookmarks to get to specific features.
On the subject of user interfaces, today’s solutions are all over the board. Geek-centric solutions might make your IT teams happy, but could alienate your project managers, product managers and upper management. Some solutions create busy-work for team members so that management can have pretty reports. Other solutions are too enterprise-y, trying to be everything to everyone, but making everything more complicated instead of more efficient. Their lack of focus makes the user experience painful – with too many links, buttons, and tables, all competing for your attention.
Finally, the lack of a comprehensive feature set makes portfolio management difficult, if not impossible. Some solutions focus on work (tickets, issues, tasks), some focus on the process (kanbans, CI/CD integration), and others focus on people (chat). But what about the bigger picture?
- How many projects do we have in flight? What’s the relative health of those projects?
- Have we spread our valued team members too thin?
- How do I find quickly find what I’m looking for? How about searching all the things (projects, users, tickets, documents)? Centralized searching isn’t something you can do without… – yep, you guessed it – buying another tool.
Next, let’s discuss the insanity of help desk solutions. It’s common for projects to deliver solutions to customers who need access to a support team. Isn’t a ticket just a ticket? Why do vendors try to upsell a separate help desk solution? Under this model, if a customer raises an issue that requires remediation by your team you end up with two tickets: one ticket in the help desk solution and another ticket in the collaboration solution. In most cases there is no inherent association between the two.
Now let’s think about turnover. When someone leaves your organization, how easy is it to revoke their access? Even if you’ve identified the replacement for a departing team member, reflecting that change in multiple projects can be cumbersome. And, once again, if you’ve been upsold both of those processes become harder.
The final point worth considering is discoverability. This may sound ridiculous, but many solutions don’t allow you to specify who is able to discover a project in the first place. If you are doing real portfolio management then knowledge sharing is critical, and you should be able to specify who can discover projects. Similarly, you should have a way to explicitly limit discoverability to certain projects.
Too Small or Too Big, Won’t Scale
Not all projects are created equal. Say that again: not all projects are created equal. In a world where organizations have dozens or even hundreds of projects, in various phases of development, support and retirement, it’s important to be able to scale up or scale down features without the headache of buying more seats or finding a new solution.
Then there’s the SaaS/Cloud versus on-premises discussion. That decision should be yours and your choice shouldn’t make deployment and management any harder. There’s no shortage of on-premises solutions, yet many require painful, complex installation and upgrade processes. Given the critical role collaboration solutions play, getting them up and running (and keeping them up-to-date) needs to easy. Many of these solutions cannot be installed at all without an internet connection for the server. This means installing a collaboration solution on your super secure network will be difficult if not impossible.
Then, once you are up and running, how do you control access to your projects? Access control varies greatly between collaboration solutions. Large projects often have large teams, with technical, management, and stakeholder members, each playing a role in successful delivery. Believe it or not, some collaboration solutions don’t allow you to define your own roles, instead, imposing a set of roles often giving users access to either too many or too few features. Roles are a key in any real collaboration solution and are often reusable, specifying the level of access users have. And even if you can specify roles on your project, if you’ve been upsold you may well be stuck having to manage access to each upsold feature separately.
This is where the tools start to run the team. What started out as only a ticketing solution soon includes a wiki, chat, help desk and next thing you know, you are looking at a bunch of tools, held together with duct tape and web hooks, none being the authoritative source of your precious project data, and all individually imposing different ways for you to get your job done. When will this nonsense stop?
Who’s Working for Whom?
That question may sound absurd but, yes, we are asking that question with a straight face. Are your tools working for you or you having to bend to their will? To illustrate, let’s start with something as basic as ticketing. Tickets are the atomic unit of work by which things get done. All your planning, distribution and tracking of work happens through tickets. In fact, most of your collaboration will be centered on the best ways to deliver the work outlined in a ticket. So why do so many systems get the most important, fundamental needs all wrong? Let’s answer that by identifying common shortcomings of many collaboration tools:
- Duplicate Tickets – When creating a ticket should the system let you know you may be submitting a duplicate? Furthermore, shouldn’t the system give you hints that maybe the problem or goal in a ticket has been addressed already on sites like StackOverflow?
- Batch Updates – Updating multiple tickets in batch should be easy to do. Yet many systems either don’t allow for this or make this far more difficult than it should be.
- Quickly Adding New Tickets – In the planning phase, it is common to create multiple tickets at once all within the same milestone or sprint. Most systems require you to rekey many of the same pieces of data instead of using sane defaults.
- Ticket Types – While the distinction about tickets is important (e.g. user story, epic, task, bug), adding flexibility shouldn’t slow the team down or make things more complicated..
- Imposing Workflow – Workflow can help teams stay on track and handle tasks in a consistent way. But your ticketing solution shouldn’t force a specific workflow on your team..
- Dependencies – Dependencies between tickets is common. Solutions should make establishing blocking/non-blocking or parent-child dependencies easy and obvious.
- Spam – Getting notifications that a ticket, sprint, epic or milestone has been changed is great, but do you really have to get a separate email for each update? Solutions should provide the option of receiving daily digests.
- Ticket Previews – Because the work in tickets can be a part of any milestone, release, sprint, etc you often need to know more detail than just the ticket number and summary. Yet, surprisingly, many solutions don’t give you ticket previews everywhere and every time tickets are referenced.
Comments <> Collaboration
Repeat after me: “Comments aren’t collaboration”. Don’t get me wrong, commenting on a ticket, wiki page, or document aids in collaboration but it isn’t true collaboration. That’s why we’re seeing all sorts of chat solutions rushed to market. Chat solutions are great and often serve as the central hub of any successful project. Here again, the upsell issue bites us but in the case of chat, it is exacerbated. Chat conversations give concise context and often include references to key project artifacts (tasks, support tickets, documents). For those exact reasons, chat should be a foundational and well-connected component of any real collaboration solution, not an upsell. For example, with an upsold chat solution, when you add a new team member you also need to manually give them access to the corresponding chat rooms or channels. And remember that problem about centralized search? Did a teammate answer your question inside of a ticket, wiki or in the chat channel? Shouldn’t a real collaboration solution answer that question for you? Why should you have to run the same search in different places?
They’re Expensive
A common problem with many collaboration solutions is that their base functionality has a high price tag. And despite that high initial cost, they have a limited scope, implementing only a few well thought out features. Make no mistake, this is on purpose – vendors use this approach to get you to spend more money. They accomplish this in one of two ways:
- The Vendor Upsell – Do you want to add a chat solution to that fancy ticketing system you bought? They have an app for that. Oh, now you want some sort of documentation/wiki solution? Yep, get out your checkbook. The problem with vendor upsell is it often creates more problems. On top of having to negotiate a new contract for each product, you are now on the hook for keeping all your shiny, new tools integrated. Now this integration may not be an issue if you are all in on cloud-only solutions but as soon as you bring any of those solutions in house you are stuck with keeping them connected.
- Marketplace Ecosystem – Some collaboration solutions get around their lack of features by offering a marketplace where third parties can offer you solutions that integrate with your vendor of choice. This has all the same problems as the vendor upsell but now you are adding another vendor to the equation which, on top of the pricing issue, it means the integrations are going to be more fragile and any breaks in compatibility puts you at the mercy of both vendors.
Golden Handcuffs
With collaboration solutions playing such a key role in Getting Things Done, the more you use them the more valuable they become. So what happens when you get to a point when you want to make a shift in how you collaborate?
For example, there are a few reasons an organization may want to move from SaaS to on-prem or vice versa and while it isn’t common, it shouldn’t be impossible, either. And if it isn’t impossible to do, the odds are the work in accomplishing that isn’t trivial. Moves like this should not only be possible but relatively easy to do.
And then there’s our friend “vendor lock-in”. You should never get into a vendor relationship that you can’t easily get out of. The upsell models makes switching out solutions even more costly, time consuming and error prone. Worse yet, if you have independent vendor solutions each itching a specific scratch, then it means those integrations will break requiring more time to keep them in sync.
What’s Irking You?
It isn’t all doom-and-gloom when it comes to collaboration software, but a solution that is right for you NOW may not be able to grow with you in the future. To that end, it’s important to understand where many of today’s systems fall short, and make choices that balance where you are today, and where you want to go. Do you have a collaboration solution driving you crazy? We’d love to hear the reason why your collaboration solution sucks.
GForge v19.1 Released!

We’re happy to announce our second GForge release for 2019 is available! v19.1 adds a number of new features and comes with a number of bug fixes.
Getting Started with GForgeNext
Highlights in GForge v19.1
Role-based ACLs for Subversion (SVN) and Git – GForge now supports role-based access controls for both Subversion (SVN) and Git. This means you can control what areas in your repository users have access to based on their role in the project. In SVN this means you can limit a roles access to certain paths in your SVN repository (e.g. write access to anything in /branches and read-only access to /trunk). For Git this works similarly where GForge allows you specify which specific branches a user has access to.
Code Reviews in Subversion (SVN) – Beginning with GForge v18.0, you could perform code reviews in Git just fine. GForge now supports the same functionality using SVN.
Embedded Video Support – You can now embed online videos in many places in GForge including tickets, wiki entries, project homepages, etc. This support is included anywhere where the GForge WYSISYG editor is used.
Commit Integrity – When it comes to commits GForge tries to stay out of your way. One example is you can associate a commit to any ticket that is part of a project you belong to but the ticket doesn’t have to reside in the same project. While that can be handy, in some cases you need deeper control so in this release we’ve added two features ensuring commit integrity:
-
- There is a new configuration option that will tell GForge to enforce the committer is currently assigned to the ticket associated with the commit.
- Another new configuration option will tell GForge to enforce the repository being committed to is the same project the associated ticket is part of.
The v19.1 ChangeLog will help you understand the changes you can expect.
Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.
The Lasting Impact of OSS Communities
Before I jump into the meat of this post, I want to point out that I was stumped on exactly where to publish this. I mean, discussing how PHP and open source software has helped me certainly doesn’t belong on a corporate website, right? The more I reflected, the more I was convinced it belonged here. We don’t market GForge as a “PHP company” but it is and my ties to the company are as strong as my history with the PHP Community (phpc). So here we are and off we go…
So Ben Ramsey hit my twitter feed with his response to this post:

To Ben’s point, I haven’t been active in the phpc since I came to work on GForge a decade ago and to get mentioned in this list of people, all of whom I respect, felt good. I wanted to take this opportunity to reflect on my path and the impact that PHP and OSS had in hopes others see the real value in those relationships.
To help set the tone here was my actual response to Ben:

My relationship with PHP started around 1999 when it was still in its infancy, back when Zend was a new company, when MySQL didn’t support foreign keys and when installing Linux was relatively painful. Back then the internet was all dial-up and I had a mini-tower PC running a version of Slackware that I literally peeled out of the back of a book on Slackware. In those days I was kidless and had just started my career and I wanted to learn as much as I could about things like Linux, Apache, networking and DNS. Being a software guy, it was a natural decision to try and setup my own website.
This day and age, all of that sounds ridiculous, doesn’t it? I mean it’s been a long time since I touched bare metal and if I need a blog, well, there are websites for that. Yet still, that decision set me on a path that I would have found unbelievable back then.
With the server setup I wanted to find an open source CMS solution and stumbled on Geeklog. Geeklog is an open source, LAMP-based CMS and at the time was lead by Jason Whittenburg. I’ve learned that open source projects are really about relationships and it wasn’t long after meeting Jason that he had me making contributions to the project before eventually handing me the project a few years later. During the next decade or so I had the chance to learn how to run an open source project and, just as important, I learned how to leverage my work professionally. How exactly?
Probably the most frivolous was I started and sold an outdoors-based community website running Geeklog. This proved to me that I could build something a company valued enough to buy it but more importantly it proved that PHP was maturing and was nearly ready for primetime.
Fast forward to 2003, I took a position in State government to help lead software development. Everything our team built was in Java and IBM DB2. Development was slow, you couldn’t run both Java & DB2 on workstation hardware back then which meant the development feedback loop was painfully slow. Thankfully I had bosses that “got it” and by about 2005 we deployed our first LAMP-based system to production. As much as I’d like to take credit for the change, Facebook’s launch put PHP into the spotlight. It was then that I recall seeing legitimate jobs for PHP’ers and software consulting firms that could find us PHP resources to augment our team. Around the same time PHP conferences started popping up not only giving the phpc a voice but allowing someone like me, in Iowa, the chance to meet many of the great people who have influenced me over the years.
While all that was going on with my work in State government, we were constantly improving our software delivery processes and tools. We went from VisualAge for Java and ClearCase to a workstation running CVS and Bugzilla to buying GForge. Back then, GForge just made the shift to a commercial-only license but we got the source code, mostly PHP, and over the years we provided a number of patches back. All of this lead to the opportunity for me to buy GForge. That opportunity was a classic case of “luck favors the prepared” but I can say my experience with Linux, OSS and the phpc made this possible.
The takeaway I want to leave you with is simple. The value of the any community is in the relationships you form. Strong relationships in the phpc can help you with more than Building Better Software. Those relationships can open up future opportunities both professionally and personally. So while I haven’t been active in the phpc, it is still a part of who I am, a part of this company and this serves a reminder that I need to rekindle some of those relationships. To that end, I’d love to hear from others like me to tell their stories and encourage others in the PHP and Open Source communities.