Why Does Collaboration Software Suck?

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.

Collaboration software shouldn't suck. Learn about some common problems to avoid.
  1. You Get Pieces & Parts 
  2. Too Small or Too Big, Won’t Scale 
  3. Who’s Working for Whom?
  4. Comments <> Collaboration
  5. They’re Expensive
  6. 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:

  1. 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. 
  2. 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.

Small Iowa Tech Inked Deals with Microchip, GE, Raytheon, BAE and Siemens

Small Iowa Tech Inked Deals with Microchip, GE, Raytheon, BAE and Siemens

Despite the technology industry being hyper focused on the next great start-up darling, one small Iowa technology company has managed to quietly ink deals with tech giants like General Electric, Siemens, Raytheon, BAE Systems and Microchip. The GForge Group, Inc, based in West Des Moines, Iowa,, has built an impressive list of clients for their collaboration platform, GForge. According to President Tony Bibbs, the success of GForge can be attributed to thinking like their clients, making sure GForge provides them the right combination of collaboration features, itching unique enterprise needs and leveraging their size as a selling point.

Enabling Real Collaboration

While the collaboration industry has long been deployed at scale to the cloud, The GForge Group has gone back to focusing on their roots of on-premises collaboration. Microchip, a global provider of microcontrollers, mixed-signal, analog and Flash-IP circuits is using GForge to collaborate on multiple levels, addressing the unique needs of their disparate teams and customer base.  Specifically, Microchip uses GForge to:

  • Collaborate across internal Microchip organizational groups.
  • Collaborate internally on Microchip products and services.
  • Collaborate externally with Microchip partners and customers.

Microchip achieves these varied levels of collaboration by leveraging GForge’s portfolio management features which allow them to organize teams, projects and customers with varying degrees of visibility.

Another key feature of GForge is the fact it is an all-in-one solution which overcomes two key problems faced in the on-premises collaboration space:

  1. Ala Cart Features – Some collaboration solutions sell similar GForge features ala cart with each having its own pricing and requiring work to configure those features to work in unison. This approach is inflexible because it means you need to know what features each project needs ahead of time.
  2. Best-in-Breed Features – Other organizations, often times unknowingly and over time, end up buying multiple products from multiple vendors providing specific features. This approach shares the same inflexibilities of ala cart features from a single vendor but this also makes integration difficult, fragile and expensive. 

GForge’s all-in-one approach makes all features available to a project but gives its customers the flexibility of scaling with the project. At Siemens, for example, they enjoy the flexibility of taking a proof-of-concept, using a few GForge features, to a full scale, mature project that has expanded to use more of GForge’s capabilities.

The all-in-one approach is paying off because large organizations recognize that not all projects are created equal and with GForge scaling with their needs they are able to focus on their strategic goals without the hassle of renegotiating pricing when the needs of a project changes.

GForge Enables True Enterprise Collaboration

While GForge gives project teams modern collaboration features (like sprints, standups and team chat), it really shines when deployed across an enterprise. For example, General Electric (GE) uses GForge to manage over 16,000 global employees, all collaborating on GE’s vast array of products and services. 

With GForge, GE is also able to specify the export control classification of every GE project, to ensure export control policies and procedures are observed in a consistent, auditable manner.

Raytheon uses two key GForge features to elevate their collaboration. Within Raytheon, there are strict security boundaries between various programs. To address that requirement, Raytheon can quickly deploy a dedicated, isolated instance of GForge for each program, giving their programs the collaboration tools they need. For projects that don’t have the same security requirements, Raytheon has a shared GForge instance for managing their entire portfolio. GForge allows Raytheon to classify shared projects for reuse readiness,to ensure systems achieve a level of maturity before they are reused elsewhere. 

GE and Raytheon rely on unique GForge features to increase productivity and reuse, and manage regulatory requirements and project risk.

GForge Leverages Its Size

Make no mistake, GForge runs at scale, and it has to in order to support such large customers. According to Bibbs, however, GForge’s true value is the fact they are a small, privately held company: 

“Being a small company, we are much more agile and far more responsive to our customer’s needs”.

 Bibbs pointed to their unique support model noting that all GForge engineers also provide direct customer support. 

“Our size allows us to use this model which has the benefit of engineers getting feedback directly from customers. Nothing gets lost or miscommunicated like you often see with multi-tier support models.” 

Another small business benefit GForge brings to the table their customers have the ability to have a direct impact on the product road map. “Listen, there’s a lot of competition in our market and there’s some big fish in our pond. Our success is tied directly to our ability to listen to our customers and, to a large extent, let them drive the direction GForge goes.” Bibbs goes on to point out GForge, despite its size, has been in the collaboration business as long, if not longer, than most of their competitors.

GForge v19.1 Released!

Role-based ACLs for Git
GForge supports role-based ACLs for Git and SVN

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.

Download GForge v19.1 Now!

Take a tour of GForgeNext!

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:

    1. There is a new configuration option that will tell GForge to enforce the committer is currently assigned to the ticket associated with the commit.
    2. 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.

Download GForge v19.1 Now!

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.

 

The Loveless Start Up – IPO Trough

I happened upon a short LinkedIn post by a gentleman named Josh Jones that caught my eye. The title says it all: “We spend too much time celebrating ‘Start Ups”, not enough celebrating ‘Keep Goings'”.

Look, I’m not here to sprinkle any hate on the dreams of Start Ups out there but the what resonated with me is his assertion we don’t celebrate the ‘Keep Goings’ enough. As I read his piece, I couldn’t help but picture an inverted bell curve of “Hype” where the ‘Keep Goings’ were bookended by start-ups and publicly traded companies:

 

 

 

 

 

Hater’s gonna hate, right? I perpetually operate with a chip on my shoulder as we at GForge hustle everyday to eat a bigger piece of pie in our market by competing against the likes of Github, Gitlab and Atlassian. Josh’s article resonated with me because the Glamor around Start Ups (who are, by their very nature in debt) and the Hype generated by big, publicly traded companies with lots of resources drowns out the successes and accomplishments of companies like ours. The ‘Keep Doings’.

On a more personal note, and at the risk of unveiling some of my own professional insecurities, Josh’s point on the emotional toll is spot on:

“…it is a dark, lonely, stressful, tough road to go down at times, there is no-one who has gone out on a mission and stuck at it for years that has not been into the darkness that is on the road to your dreams.”

I want to leave you all with just three thoughts:

    1. I’m painfully aware that being drowned out by the Hype generated by Start Ups and big, publicly traded companies is in part a fault I have to own. The GForge brand isn’t where it should be and the accountability sits with me. I only say this to be clear I’m not simply whining about what they are doing right.
    2. If you are a consumer of B2B solutions and services I ask you consider critically if going with a flashy Start Up, however well funded they are, is better than a proven solution from a company with a solid history and track record. Similarly don’t fall into the “people don’t get fired from buying Microsoft” line that I’ve heard more times than I can count. That’s not a good reason for going big.
    3. More importantly, I want to hear from the other ‘Keep Doings’. I know there are more of us out there and reading Josh’s piece really gave me perspective and some calm knowing there are a lot more of us out there hustling Every. Single. Day. Come out of the shadows, tell your story and share similar experiences you have had.

 

GForge v19.0 Released!

We’re happy to announce our first GForge release for 2019 is available! v19.0 adds a number of new features and comes with a number of bug fixes.

Download GForge v19.0 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Highlights in GForge v19.0

Sprint Retrospectives – For Agile and Scrum teams GForge already lets you create, track and manage the burndown of your sprints. In 19.0 can now assess and reflect on sprints with Sprint Retrospectives. Retrospectives include a report of key metrics and then allow you to provide a narrative to identify what worked well, what challenges you had and come up with actions and ideas going forward.

Tickets: Related Items – A challenge for all teams is reducing duplicated work. When creating new tickets, GForge will now identify related items allowing you to quickly determine if you are working on a problem that has already been identified and possibly fixed. GForge can show its own related tickets as well as possible matches on StackOverflow.

Offline Installation/Upgrades – If you need to install or upgrade GForge in a secure location in your network on a host that doesn’t have outbound internet connectivity GForge now supports offline installations and upgrades.

Moderated LDAP/SSO Accounts – You can now configure GForge to send new accounts registered via LDAP/SSO to a queue where they await formal approval by a GForge Administrator.

Organization – For customers with large project portfolios you can now organize your project into organizations. Organizations also provide the organization a place where they can collaborate across projects inside the organization.

  • The v19.0 ChangeLog will help you understand the changes you can expect.
  • The GForgeNext FAQ will answer most of your questions but don’t hesitate to send additional questions.
  • 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.

Download GForge v19.0 Now!

GForge and Open Source Software

Old School OSS

I can recall the low beam of light from a CRT monitor that was hooked up to a 333MHz Intel Pentium II computer that provided just the right amount of hum from its tower to compliment the loud clicks I was orchestrating from my cheap IBM keyboard. I was sitting on an equally cheap, metal folding chair positioned perfectly in front of a card table that hosted the monitor. That was the scene as I made my first open source contribution, using Slackware 3.x.

Today, I can replay all the different ways open source software shaped my professional career and the vision and value systems we hold here as we reinvent and reintroduce GForge.  Admittedly, many familiar with GForge know it more from its roots at SourceForge.net and its impact on open source software back in the 1990s. A lot has changed and open source software has continued to thrive beyond its original, organic roots to claim a rightful place in organizations of all sizes.

Today’s OSS

There is no industry immune from the influence of open source software. Cloud computing, DevOps, fintech, medicine, banking and governments at all levels are deploying some level of open source software but what gets lost in the fray is their true relationship with open source software.  There could be more, but I see three distinct relationships an organization can have with open source software.

  • Consumers – These organizations simply consume open source software. This could be viewed negatively but having led an open source project I can attest that there is a tremendous amount of pride seeing people use software you helped build.
  • Contributors – While they also consume, these organizations also make contributions back to open source projects in the form of bug reports and possibly small patches. Finding bugs is hard work that open source projects appreciate and nothing feels better when someone using code you helped build finds and submits the fix.
  • Collaborators – The organizations I respect most not only contribute but they actively collaborate on open source software. These are the organizations that understand that OSS is more than just source code, they are communities with vision that sustain real, long-standing relationships that cross industries, geography, religion, politics and socio-economics. I can’t begin to enumerate the number of great people that have influenced me professionally and personally as a result of open source collaboration.

GForge and OSS

Ok, I can hear you asking “Where is this going and why write all this when GForge is a commercial offering?”  As an organization GForge sits in that “Contributors” relationship with open source. While that’s not bad, we do have aspirations to improve our relationship and we have chosen to apply the principles we’ve learned from open source in how we engage in business. Specifically:

  • You get our source code – While GForge is a commercial product we ship the source code for our entire codebase minus the bits that do the license key checking. Also, GForge is free for up to 5 users and is free to open source organizations.
  • We value transparency – Providing our source code can be viewed as a risk but for our customers it allows them to do a deeper inspection of our features, code quality and they can perform their own, independent security audits.
  • Security vulnerabilities are good – Sadly, my name is associated with some pretty nasty vulnerabilities and there are only four appropriate things to do when that happens: 1) swallow your pride 2) thank and give the reporter official credit 3) find, fix and announce the vulnerability quickly 4) learn from the mistake.
  • Better customer relationships – We make it possible for customers to access our codebase via Git. This not only makes customizations possible it makes those changes maintainable over time while still take advantage of our new features and bug fixes.
  • Avoid vendor lock-in – We are a vendor so you probably think vendor lock-in is good, right? I’ve been on both sides of this table and by providing our source code, by using an open source database (PostreSQL) and providing a slick REST-ful API we are conveying to our customers and prospects that we know they have choices and our open approach is the foundation for the relationships we build with our customers.

GForge Going Forward

Last month we reintroduced GForge with our first release of what we dubbed “GForge Next”. Our goal was to make GForge Comprehensive, Simple and Elegant by paying down over a decade of technical debt that positions us to focus innovation.  GForge has a long history with open source software that we plan to expand on and if the above values resonate with you, we invite you to explore what we’ve learned in 20 years of helping teams Build Better Software.

Learn More about GForge Take a Tour

Download GForge or Host a Project with us