PHP Contract Opportunity

The GForge Group has two open contract position for PHP developers to help with improving GForge Advanced Server and providing customizations for our customers. This position is expected to last approximately 3 months. All submissions received at on or before June 20th, 2014 will be considered.

What We are Looking For

  • Work from your home or office.  Iowans will get an extra look but we are open to candidates living elsewhere in the United States or abroad.  The only real requirement we have is candidates must write and speak English well.
  • Knowledgeable in Linux/Unix system administration including Apache+PHP installation and configuration, scripting (bash, etc) and package management.
  • Serious programming chops.  While qualified candidates must be proficient in PHP, the best candidate will have real-world experience in additional web-based languages.  The candidate must also be solid with SQL (PostgreSQL a bonus), JavaScript (jQuery a bonus), Git, REST, SOAP.  ORM experience would help (Doctrine or Propel a bonus).
  • Open Source Advocate. Most of the software we work with is based on open source technologies.  We want candidates familiar with using open source development tools and prefer people who are or have contributed to open source projects.
  • Someone who embraces teamwork and can keep up in a face-paced environment.  Must be able to stay focused, yet knows when to ask questions.


  • Work will include roughly 70% backend PHP development and 30% frontend work.
  • Perform code reviews (pull requests).
  • Attend weekly, online sprint planning meetings (Mondays).
  • Attend daily, online stand-up meetings.
  • While we expect you to be working roughly 8am – 5pm CST, Monday-Friday we can be a bit flexible.

Warning to Consulting Shops

This isn’t our first rodeo.  We are looking for a first-round draft pick so help us by not wasting our time with junior level candidates.  Please send us no more than two candidates from your company.  We have a long memory so we will remember who sent us serious contenders and we will definitely factor that in on future opportunities.

GForge 6.3.1 Released

Today we are happy to announce the immediate availability of GForge Advanced Server v6.3.1.  This is primarily a bugfix release and the highlights include fixes for the Support Tracker feature and some minor security enhancements.

Download GForge Advanced Server v6.3.1 Now!

Support Tracker Fixes

If you haven’t already tried out the Support feature in GForge AS 6.3, you definitely should.  Here are a few key fixes and enhancements to that feature:

  • [#15070] Support tracker: Member group not set properly.
  • [#15071] Support tracker: skip first notification after the TI is submitted and set the timestamp
  • [#15134] Support group and assignee lost.  Suspecting cron15.php
  • [#15151] Support tracker: autoclose sets close date correctly  but it’s not visible in browse or TI pages.
  • [#15433] Filter “Out Of Office” replies (and similar automated messages) from creating support requests in GForge

Miscellaneous Improvements

There are also a few other improvements that warrant a quick mention:

  • [#11848] Mass Delete broken
  • [#19112] Navigating wiki versions doesn’t quite work right.
  • [#19246] License Tracker – Valid user gets access denied
  • [#19258] Docman allows uploading of HTML files which can have spam  possibly JS making it possible CSRF vuln
  • [#19388] My Account > Disable Account not working
  • [#19221] When parsing files  filesystem_index cronjob could trigger a tracker item notification
  • [#11830] Fix xss vulnerability in tracker item edit screen
  • [#19331] Sanitize paginator parameters
  • [#19847] MAG: change default database name to “gforge” instead of “gforge5″
  • [#19649] upgrade_gforge – Unused plugins cause confusing output

For full details, please have a look at the Complete GForge v6.3.1 ChangeLog

Download GForge Advanced Server v6.3.1 Now!

How Valuable Are You?

A long time ago, I learned some great criteria for taking or keeping any job.  I mean, like, a long time ago.  Like, before Google.

Here they are, in random order – apply your own prioritization:

  • Will you be successful? That is, will you deliver projects, make money, become famous, get the girl, whatever it is that you want.
  • Will you learn something new?  Might be technical, might not.
  • Will you be valued?  Will the people you’re working with (and for) be capable of understanding your contributions?  Will they appreciate your contributions?

For me, the third bullet has always been the toughest to find or keep.  Maybe that’s why it is my most important criteria.  Or, maybe it was already my most important, and I just noticed how much trouble finding it could be.

So, how do people make themselves valuable?  I’ve seen two basic approaches in the twenty or so years I’ve been doing this.

The Wrong Way – What You Keep to Yourself

Historically, people make themselves valuable (and/or powerful) by becoming the choke point for information, or approval, or funding, or whatever.  When only one person in your organization is allowed to touch the requirements (or the database, or whatever), you may be dealing with someone who measures their value this way.


“I take the requirements documents from the customers and bring them to the developers”

He may have people skills, dammit, but he’s not helping the team – he’s making sure that they can’t get along without him.  Or so he thinks.

As a manager, I can tell you that my biggest HR risks are always the people who bottleneck knowledge, process, money, whatever.  If they get hit by a bus, decide they want a big raise, or take an extended vacation, we’re hosed.  They have knowledge, skills or connections that we can’t easily reproduce.  So as the person who’s responsible when bad things happen, I’m going to actively pursue this person’s secrets, and make sure they’re backed up somewhere, by someone.

If it sounds like a bad situation for the team, it is.  But it’s actually just as bad for the person, in most cases.  Ten years ago, I started a new job as a team leader.  The biggest complaint from the team was that they were each chained to a given project.  They were the only person on the project, they carried all of the knowledge, the relationship, and the responsibility.  They couldn’t move on, they couldn’t learn anything new.  They were just stuck.  For most people, this does not feel like success.

A year later, we had standardized our process, the documents we used, even much of the code templates.  People were able to move from one project to another.  They were even able to talk to each other about different projects using common terms.  There were a few people who didn’t like this change, even though they had complained about lack of mobility.  Those folks still hadn’t adjusted their way of measuring their own value.

The Right Way – What You Give Away

Plenty of good engineers are collaborative by nature – that is, they enjoy sharing their knowledge and getting some of yours in return.  And while it’s certainly a more friendly way to work together, it’s also more productive, more robust and more resilient, especially in the face of team or project changes.  But believe it or not, giving away what you know actually makes you more valuable as well.  Think about how valuable Stack Overflow is today, and you’ll see that it’s true.  Compare SO and its success against ExpertsExchange, which largely hides answers behind a paywall.  EE might make some money, but SO rules the world.

Being an “open knowledge” kind of person is also the best defense against Competence Debt and other creeping forms of team decay.  So as a team member I like the approach, but as a manager I demand it.


GForge: What’s Next?

The Pitch

Won’t you make some time to come help us build and perfect GForge Next?  Just leave a comment – we’ll be recruiting First Dozen candidates through the end of April, and would love to hear from you.  If you can’t make it for May, then we’ll add you to the invite list for the Next Hundred phase.  Send a link to anyone that might be looking for a better, more powerful and more cost-effective tool for tracking tasks and collaborating on projects.

First, A Bit Of Background

If you’re already familiar with GForge and what it does, feel free to skip ahead.  If not, you’re in the right place.

GForge is a commercial product built and maintained by the GForge Group.  It was originally started as a fork of the Sourceforge code nearly 15 years ago.  It’s a project collaboration web application that includes a ton of modules for each project, from task tracking to version control, mailing lists and forums to wiki pages and blogs.  It has very broad and deep configurability, and nearly everything can be access-controlled to specific (and configurable) project roles.  Pretty much everything gets logged in an audit table for traceability, and there’s reporting almost everywhere.

Most of our customers are large, engineering-oriented shops with CMM, DoD or other stringent standards to meet, across dozens or even thousands of projects.  Think chip makers, defense contractors, gigantic world-wide engineering and manufacturing conglomerates, that kind of thing.  We license the code to our customers, and they have access to that code for their own security analysis, review or customization purposes.  We’re extremely customer focused.

The Problem

I’ve been at GForge for nearly two years now.  In that time, we’ve added some significant new features (chat and support trackers come to mind), cleaned up a lot of old code, and generally moved the product forward in lots of very gratifying ways.  Before working for GForge, I was a customer for nearly ten years, so I developed some pretty clear ideas of what was special about the product, and what could, uh, use some work.  And while we’ve done many of the things I had in mind, in the end, it’s not enough.

The features, the integration between them, and the data – those are all very solid and still very relevant in 2014.  But the existing GForge code, the existing layout and user experience will just never do the things we want them to do.  The structure of the code is out of step with current patterns, and simply won’t work with autoloaders, Composer and other tools that make PHP so productive in 2014.  Much of it isn’t very testable.  There’s all manner of technical debt in the old code, like raw HTML output from domain models, overly-complicated URL parsing and generation, and so. many. different. pages.

To build the next GForge, we’re going to start from scratch – well, sort of.

Existing GForge Customers: This plan involves a gradual re-implementation of the features currently available in GForge AS.  There is NO plan to end new development or support for GForge AS, and there won’t be any plan until GForge Next is ready for prime time.  Just as we did with the 5.x sunset, existing customers will have plenty of time to evaluate, test and migrate from GForge AS to GForge Next.  We will develop and support both GForge AS and GForge Next for quite some time, and we’ll make sure that the transition is low-risk and high-value for you.

The Plan

To build GForge Next, we’re going to write brand new code on top of the same database.  This means that we’ll be able to check what the new code does by reading and running the old code, using the same data.  It also means that as people start testing GForge Next, they will also be able to switch to (old) and see the exact same data.  Or do something that the new code doesn’t support yet, which brings me to my next point.

The existing features are broad and deep.  In fact, they can be distracting or downright intimidating for new users, who don’t need that kind of power or flexibility.  So we’re going to deliver GForge Next in roughly four phases, outlined below.  The first phase will be focused on task tracking and version control.  It’ll be very simple and very opinionated – many of the choices you could make in the current GForge release will be pre-set and not configurable.   Subsequent phases will add back the existing GForge features, but with carefully reconsidered user experiences, and (wherever possible) mobile and touch-friendly rendering.

Our phases revolve roughly around the size of the testing user base, as follows:

The First Dozen (FREE!)

Starting in late May, we’ll have a very basic, low-friction version of GForge Next deployed and running.  We’re looking for about a dozen people/groups to use it on a daily/weekly basis and work closely with us to ask questions, tell us what works (and what doesn’t work), and basically give us lots of feedback.  In return, we’re going to update the site many times each week (or each day), tweaking the look and feel, fixing bugs and adding features constantly.

Main features for The First Dozen will be pretty basic:

  • Login – Using a GForge account, or others (possibly Github, G+, even Stack Overflow?)
  • Create a Project
  • Invite users to your project
  • Project Chat – Ever-present contact with the entire project team.  Archived, searchable, and integrated with the other GForge Next features.
  • Git repo (including the option to clone a remote as part of the project setup)
  • Kanban Task View (we call them Tracker Items)
  • Tracker Item Browse – a more tabular view than Kanban, with more filtering, sorting, export and edit capability

The goal for this phase is to allow small teams or casual users to test GForge Next with their existing code, with less than 5 minutes of setup time.

The Next Hundred (Still FREE!)

In late July or early August, we’ll add up to 100 users/projects to our test group, and the following features:

  • Sprints – Group Tracker Items, track velocity for each Sprint
  • Super Search – One search bar, in the same place on every page.  Searches everything you’re involved with, and shows results by project or module.
  • The “G” Mega-Menu – Super-simple navigation across everything you might need
  • Git repository browser – See tags, branches, file tree, revisions, commits, and diffs as part of the GForge Next interface
  • Batch Import – Create a bunch of Tracker Items with as little as a title for each.  Paste lines into the box and voila.
  • Activity Stream – See a real-time feed of who’s doing what on the project.  Commits, Kanban and Tracker Item changes, all that stuff.
  • Pull Requests – View and comment on the diff, iterate on the changes, and promote new code, all on the GForge Next server.
  • Standup Report – Get your story straight a the daily, weekly or random standup in 60 seconds or less.  Then everyone can share their 1/2/3 list quickly or review it later via web.

 Open For Business

Late this year, we’ll launch the paid version of the service.  Projects from The First Dozen and The Next Hundred will get free or heavily discounted rates, as will qualified open-source projects and even some startups.  This version will include practically everything currently included in GForge AS, plus some all-new features and capabilities:

  • Workflow Design – Fully-customizable Tracker workflow.  Define who can move a Tracker Item to each status, require fields based on the new status, trigger scripts, set/update fields.
  • Reporting and Charting – Powerful data gathering, filtering and sorting, combined with tabular and printable views, file export, and charting.
  • Project Homepage
  • Wiki
  • Kanban Setup – Define your own custom planning board.  Choose almost any field for the columns (like release, assignee, sprint), group values together, show aggregates for each column (like count or average size).  Save and name your board and let the whole team use it.
  • Organizations and User Groups – Define organizations and put projects under them.  Create groups of users (like customers, vendors, or various departments), and give those groups access to what they need.
  • Customer Support Tracker – Currently available in GForge AS 6.3, give your customers the ability to submit and update tickets.  The customer view shows only those Tracker Items that belong to the user’s group or organization.

But Wait, There’s More!

Starting in 2Q 2015, we’ll add even more:

  • Discussions / mailing lists
  • Social features – Upvoting, endorsements, suggestions based on friends of friends or shared technology between projects.
  • Document Management – The powerful docman module currently available in GForge AS 6.3.  Drag-and-drop upload/download, versioning, comments, even inline edit for text/html.
  • Release Management – Build a roadmap of product versions, and manage the set of Tracker Items in each release.
  • Request To Join
  • Project Fork – Clone the setup and the Git repository for an existing GForge Next project.
  • Blog/CMS Module
  • Tracker Detail Designer – Lay out the Submit or Edit form your way.
  • Migrations from Github and Jira
  • Enterprise Login – Install GForge Next inside the firewall and use LDAP, SSO, or OAuth for your internal user base.
  • SVN and Mercurial support
  • Jenkins Integration – View and kick off Jenkins builds from GForge Next.  Install the Jenkins plugin and give project users seamless access to their GForge Next projects in Jenkins.


Engineering Problem, or Tool Blinders?

Tony and I met with a former co-worker early this year, to talk about his use of MongoDB.  For some reason, they thought Tony was an authority on this.  I just came along for the lunch.

The Question

The gist of the discussion was this:  how best to store large binary objects in the database?  Was Mongo the best choice, or would PostgreSQL be better?  They were using both, but some devs were making a concerted effort to get over to MongoDB for new work.

After about 15 minutes of (kinda non-) discussion, I butted in: “I think you’re asking the wrong question.  Do those files even NEED to be in the database?”

Metadata about the files?  Absolutely.  But the files themselves, probably not.

The Actual Problem

Databases are good at a few things:

  • Finding things quickly (indexing, hashing, etc.)
  • Keeping things straight between many competing threads (ACID stuff)

You know what they’re usually bad at?  Sending or receiving large field values (I mean > 512KB or so), especially within a transaction.  Especially under heavy concurrent load.

I can hear the DBAs out there yelling at the page that of course it can be done.  I didn’t say it was impossible, it’s just soooo not what database are good at.  While various database platform vendors have tried mightily over the years, storing large objects in your database is still possibly the worst physical database design decision you can make:

  • Worse than adding all of your query fields to the PK.
  • Even worse than getting involved in a land war in Asia.
  • Worse than, (gasp), stored procedures?  Well, that might be a closer race, but let’s leave stored procedures for another day.

The GForge Approach (is nothing special)

I’ve always thought that GForge handled files in the clunkiest, lowest-tech way possible – on the file system.  It still does, and even the Big New Version will continue to do so.  But it wasn’t until this discussion that I actually became an advocate for this approach.  Why?  Because it’s only clunky until you compare it to all of the other approaches.

GForge stores all of the metadata (date, name, size, author, project, etc) in the database, we even add some keyword indexing in PostgreSQL’s excellent tsearch facility.  But when it’s time to upload or download one of these files, we use FTP or HTTP.  We get away from the DB when it’s time to do something that might run longer than a second, and we play to the design strengths of those other protocols.  And while nearly all of our customers service web and file traffic from one server, GForge does allow configuration of different hosts to offload those tasks.

This shouldn’t come as a surprise to anyone.  It didn’t really come as a surprise to our friends that asked the original question.  But I could tell they didn’t really want to hear that the best solution didn’t involve new, shiny stuff. I understood that, and I still do.  The best coders are the ones who do it even when no one’s paying them, just to try things out and learn.  You don’t want to squash that initiative, but it can’t be your main criteria for choosing tools to solve business problems.

Have fun out there, just don’t let the shiny get in the way of the job.



I heard from my former co-worker a couple of weeks ago.  They went with S3 storage, indexed metadata in a (PostgreSQL) database, and links between the two.  They managed to find a solution that was both powerful and shiny.  Kudos to them!

Code Upcycling: Evolving Legacy Code

Last October our engineering team met up in Buenos Aires, Argentina and CTO, Michael Tutty, talked about the challenges of improving legacy code.  Developers are notoriously guilty of insisting a full rewrite of code, particularly when it wasn’t their code to start with.  But what if that code is already to market and generating revenue?

In Michael’s talk, “Code Upcycling: Evolving Legacy Code”, he explains The GForge Group is dealing with this and he gives a few realistic alternatives:



Support Driven Development – Making Support a 1st Class Service

Start-ups often struggle with navigating the sea of development tools and the focus is almost always on the basics of source code management and issue tracking.  Some roll their own point-based solutions by spinning up their own Git server and installing some open source issue tracker while others head to the cloud and try to tie these things together with APIs (which often leads to additional problems).

However, once the team puts the polish on the initial release and begins planning the rollout it is only then they realize they have to tackle support.  This is a critical misstep.  Support should be one of your first concerns and it should be dealt before the first line of code is written.  How software shops provide support should be part of the conversation back when they were tackling source code management and issue tracking and while they may not rollout a support solution immediately, the process and tools they will use should be finalized.  Why?

The end of a development cycle is often the most chaotic.  While the final tests are being run and packages are being built, plans are being made for the big release announcement and plans for the next version are already underway.  Trying to iron out the support process and tools at the end of a development cycle, with everything going on, almost certainly means what ever decisions they make will be done in haste and that anything they rollout will feel like a 2nd class citizen to their customers.  Is this the first impression customers want?  Absolutely not!

We learned this lesson the hard way.  We made all those missteps and are still paying the price.  In short, a poorly thought out support process and bad decisions in support tools is just another form of technical debt.  As a result we have had to address an out-of-date support process and aging tools just as we have to address other forms of technical debt (e.g. poorly written, untestable code, out of date processes, etc).

So it was about a year ago when my CTO came to me with a pretty simply revelation.  GForge Trackers already allows you to customize the data you collect and to define a workflow process for managing tasks, bug and enhancements.  Why not expand our use of GForge Trackers to support?  In version 6.3.0 we added Support Trackers to GForge.  As with any new feature, we’ve had a few kinks to workout, however, the decision is already paying off.  There are so many benefits to managing support within the same system you use for managing your issues and tasks:

  1. Support tickets can be managed by a separate team but using now your support and development teams are using the same tools.  This simplifies training and allows each team to have visibility into what the other is doing.
  2. Managers can generate reports on support tickets and bugs in one system.
  3. Support tickets can be escalated to bugs, giving a clean hand-off from your support team to your development team.
  4. Support tickets can be associated with issues and tasks, retaining the relationship between them.
  5. Support tickets can be part of your sprints.

Sprints?  Yes, with GForge v6.4.0 we will finally support sprint planning.  While managing sprints in GForge is pretty cool, we never imagined ahead of time we’d be including support tickets in our sprints.  However, after rolling out an alpha version of the sprint feature, we found that with a small team that provides both development and support that this was the perfect way to stay on top of everything and we couldn’t be happier.

If you agree great support is something your customers demand, the points we want to leave you with are simple:

  1. Iron out the details of how you will provide support before the first line of code is written.
  2. Try your best to avoid hard-to-integrate point solutions or clunky cloud-based APIs to tie support, issue tracking, etc together.

GForge Advanced Server allows everything from start-ups to enterprise-size organizations a way to provide support to their customers in the same tool their teams use for source code management, issue tracking and collaboration (chat).  Learn more about GForge Advanced Server or download it today.



Get every new post delivered to your Inbox.

Join 1,679 other followers