GForge Next – The API

A couple of weeks ago, Tony shared some screen shots of GForge Next, and talked about how we’re designing it to Get Out of Your Way.  Today, I’d like to talk about the other end of GForge Next – the API side.

We’ve Always Had An API

It’s true – the current GForge has an API, and it has for over ten years.  But it’s……not awesome.

If you have ever worked with SOAP services, then you know they can be overly complex, verbose and yet inscrutable.  Not to mention it can be fragile, especially between different platforms (I’m looking at you, Java/Axis/Axis2/XFire).

But the real flaw in our SOAP API is that is was bolted on to the existing code.  There’s quite a bit of logic shared between the GForge UI and the SOAP API, but also some duplicate code, so the API won’t always act the same way as the good old web UI.  As we continue to fix bugs and add features, it continues to be an extra effort to maintain these separate code modules and keep them working the same way.

Now With 100% More REST

Like everything else with GForge, we are our own worst critics, and our own first users.  So it was easy for us to decide that to be useful, the API had to be an integral part of the system.  The entire GForge Next UI runs against the API.  Logging in?  API call.  Getting your list of assigned tasks?  API call.  When we use GForge Next UI to accomplish tasks, we’re also automatically making sure that integration via the API will work for all of those use cases.

For wire protocol, we chose REST (like pretty much everyone else these days).  JSON + HTTP (GET, POST, PUT, DELETE) is a pretty simple, readable and capable combination, and it aligns nicely with the other parts of our technology stack (like AngularJS and Bootstrap).

The API is even self-documenting thanks to code-comment blocks in the underlying services and our /apidoc endpoint.  The API docs include all the entities, methods, parameters and even example input and output.  As we continue to add and change the API , the docs are automatically up to date.


For the most part, we submit data to the API using the same JS objects we receive from it.  That way, we can take an object from a list of values, assign it as a property on another object and submit it.  Super-simple on the client side, and pretty easy on the server as well.  But for external integration, it’s not so great.  Requiring callers to fetch a bunch of lists and sub-objects in order to properly craft a request makes the API less usable and more prone to invalid requests.  So, for most requests, we will accept any of the following values for sub-objects (like a project, a status, the user, etc.):

  • The “official” JS object for that type (retrieved from the API)
  • The ID or alias for the object, as a number or string value.  For example, ID 2000 or the short name mtutty for a user.
  • A JS object with an ID property, with the same value as the above bullet.

In general, the API back-end will work pretty hard to figure out what value you’re trying to use, and go find it based on the ID or key value submitted.  We also support vanilla FORM POST semantics, so that regular HTML forms, curl and wget requests are easy to do.

Complex Can Still Be Simple

So it’s pretty easy to create a basic CRUD API for a set of related tables.  The current GForge Next database has about 137 tables, which is a bit more complicated.  Add to that the fact that most realistic use cases (including our own UI views) are going to need multiple types of data, and using the API just went back to difficult and confusing.  Well, maybe not.

Largely for our own needs, we started adding related data as optional for many API calls.  By adding “rel=xyz” to a GET request, you can ask the GForge Next API for additional data that is related to the entity (or entities) you’re requesting.  So for example, GET /api/user/mtutty/details?rel=projects,activitylog includes the most-used projects and most-recent activity records for me.  That’s all the data needed for the user profile view, in one call.

Don’t need all that extra stuff?  Don’t include the rel, and you can get the payload down from 3.6K to 963 bytes.

How About Some Examples?

Here are a couple of ways we’re already using the API (outside of our own UI) to keep project data and knowledge moving, even when things are happening outside of GForge.

Build and Deployment Activity – We use Jenkins for CI/CD (and deploy GForge Next several times every day).  Whenever builds start or fail, or whenever a deployments starts or ends, we use the REST API to log an activity record.  This is visible in the Project Home page activity view and in the project chat room (which is where we see it most of the time).  Now as we’re working on tasks, we can see not only what tasks other people are working on, and their funny cat pictures, we can also see our build kicking off, and code going live, in real time.


Customer Feedback – First Dozen users will notice the green “Feedback” tab on every page in Next.  That tab submits data to a separate Tracker called, well, “Customer Feedback”, using the API.  Technically it’s part of our site but we have made a conscious effort to keep it separate from the AngularJS application that contains the rest of GForge Next.  The Tracker template will be available in GForge Next, and eventually we’ll make the widget available too, so customers can collect feedback from users directly into their GForge Next project.


Where To Go From Here

While we are excited for the new REST API in GForgeNEXT what really excites us is the creative ways developers will use the API.  Because the API is new and will continue to develop, we really hope you consider signing up for early access to GForgeNEXT. Those requesting early access will can expect the beta to begin officially over the next couple of weeks which will include immediate access to the API.

Getting Out of Your Way

When I talk to customers about GForge, I often describe it in terms of parenting.  For product managers, their products are their children and good parents see all the untapped potential alongside any rough edges.  Like parents, product managers often spend a disproportionate amount of time playing up their products strengths while downplaying those rough spots.

GForge and nearly every product in our space shares a common flaw: we get in the way too much.  Product managers fantasize about how much customers use their products and, while understandable, sometimes the measure of a great product or feature is how much it gets out of our way. Let’s explore this concept with a concrete example.

As we’ve been redesigning GForge, everything related to the customer experience is on the table.  Over the past few weeks we’ve been finishing up how leads, PMs and individuals manage their work.  For most organizations this means multiple projects with competing priorities fighting for engineering time.  This process usually goes through a review by leads or PMs resulting in work being dished out to team members who then have to figure out how to factor those competing project priorities to build their work queue.  Worst yet, this process often happens multiple times each week with the team members organizing their queue on a daily basis.  Compounding things, each organization has a toolset that is meant to facilitate some or all of this process and here-in lies the problem.  While the tools often facilitate organizational process, they are often clunky and impose team members to do interact with the tool more than needed.  This is the exact sort of problem GForgeNEXT is trying to fix.

So what are our goals in the specific case?

  1. It has to be easy for leads and PMs to prioritizing work ahead of assigning tasks to team members.
  2. Leads and PMs want to quickly prioritize team members tasks, many of which, reach across milestones or other projects.  To be clear, we are talking about prioritizing work across projects and milestones where tasks, in many cases, have been given the same priority.
  3. As an alternative to #2, above, some organizations prefer to give team members the flexibility of prioritizing their assigned work across projects and milestones.
  4. Leads and PMs want to monitor an individual’s contributions and tasks (again, across projects and milestones).
  5. Team members want to work through their queue without having to constantly refer to to their list.

To drive home the need of tools needing to get out of the way of teams let’s show how GForgeNEXT addresses this.

Prioritizing and Assigning Project Tasks

Admittedly, GForgeNEXT isn’t doing anything truly revolutionary in this area.  The fact is to prioritize and assign work on a project, you simply can’t get around building a list and then setting the priority.  In fact, you’ve always been able to do this quite well in GForge but we did add a few wrinkles to make this easier.  First, when building your list, we’ve made it easy to quickly add a tasks:


As you see, you can now save and quickly navigate to add additional tasks eliminating the step of going back to any list. Once you’ve built your list you can further refine the priority and assignment of tasks:


One minor feature we added is the ability for team members quickly add a task to their own queue.  While browsing tasks they can click on the star icon which will a) assign the task to the team member and b) add it to the end of their current queue:


Probably the biggest enhancement to the task list is that they are all part of a polling loop to reflect external changes. That means if you are working through prioritizing project work in a phone call or meeting one person can change the priority (or status, assignee, etc) and anybody else viewing the same page will see the changes.

Prioritizing Work Across Projects and Milestones

To this point we’ve shown how to manage tasks within a project, however, if you are in an organization with multiple team members working in a growing project portfolio you need to have a handle on how that work is prioritized work across projects with competing priorities and deadlines.  This is equally true for team members who may have the flexibility to make their own decisions on how to prioritize their tasks across projects.

In GForge you could already view your assigned work and even manage that work within your own queue.  While the feature is there and it works GForgeNEXT simplifies all this:


What you see above really addresses three basic questions for any given person:

  1. What has this person been assigned?
  2. What are they currently working on?
  3. What have they completed?

If this sounds familiar, that’s because this is what nearly every “status meeting” in nearly every organization has covered for decades.  “Status Meeting”, “Stand-up Meeting”, call it what you want, those are the three basic nuggets of information they are all after and they account for significant productivity waste.

When viewing an individual’s queue, GForgeNEXT gives you the answer to those three questions.  See, access to an individual’s queue is based on the relationship of the viewer, specifically, leads and PMs can now monitor and optionally manage their team member’s queues.  Obviously this also implies users can manage their own queues and all of this is done by dragging cards between the Assigned and Queue columns or moving cards within the Queue column to set the order.

Finally, just as when browsing tasks, when you are viewing an individual’s queue, any external changes made either by the individual or a lead/PM will be automatically reflected .

Working Through Your Queue

Once the lead, PM and the individual have setup their respective queues team members can begin work.  What’s important here as while the queue exists we have tried our hardest to make complete taskseffortless. For example, you can quickly view your queue fight from the menu in GForgeNEXT:


From there, as you complete work in your queue you can simply access the next item using the What’s Next button which will save your work and take you to the next task in your queue:


Again, Let’s Get Out of Your Way

As I’ve said before, we don’t pretend any of this is truly revolutionary but as we continue product development on GForgeNext we continue to not only listen to our customers but figure out how we can reduce friction so your teams can focus on getting work done.  Regardless of whether you use GForge or not, let us know how your organization manages work and if what we outlined would fit your organization.  Finally, If you’d like to take a closer look at GForgeNEXT we invite you sign-up for our beta program which will be launching soon.

Maslow for Startups

Abraham Maslow was a psychologist and professor.  He designed this great hierarchy of human needs:

Maslow's Hierarchy

A simple version of Maslow’s Hierarchy

Basically, it says we need to breathe before bothering with staying warm.  And we need to eat before worrying about having any friends.  And we really can’t spend any time following our dreams until we’re clothed, fed, warm, have some friends, and overall feel pretty good about ourselves.

It seems natural to me that product-driven companies would follow a similar sort of hierarchy.  There’s a fairly common progression of needs that a company must satisfy in order to survive, grow and succeed.  In trying to figure out which GForge features you’ll really need, and in what order, I’ve come up with these buckets and given them catchy Greek-themed names.  We’re using these buckets to guide our feature deployment for GForge Next, so that we meet the needs of new users easily, and give them more features as they begin to need them.

Group 1: Atlas


The most basic level of business development.  This model depends heavily on large efforts by a small group.  Their roles, interactions and dependencies may be somewhat defined, but most processes are still ad-hoc, and are created, revised and discarded based on immediate needs.


Generally, boot-strapping – that is, getting to market on little (or no) financial budget.  Initial product/service delivery to see if the business model is viable, or trying to bring in the first customers to fund further expansion.


Atlas groups tend to:

  • Spend Time/Effort instead of Money

  • Be Flexible as opposed to Repeatable

  • Depend on A Few Heroes instead of Divide and Conquer

  • Prefer Simple Process over Robust/Complex Process


  1. Task/Issue Tracking – First and foremost, a persistent list for who is doing what. The group is very small, self-directed, and self-organizing, so features like metadata (e.g., severity, milestone, priority, workflow by status) and access control are not important.

  2. Version Control – Whatever type of product (software, design/creative/mkting, manufactured goods, etc.), there will be some kind of source code, documentation, images, or other output to be kept safe and trackable over time.

  3. Project Chat – A live, persistent and searchable scratchpad for quick discussions, news and humor without having everyone leave their desk.

Group 2: Vulcan


The first big change in team organization.  Initial product may be out, customers calling for support, feature requests, etc.  Team’s focus is still more tactical, day-to-day, but the group is growing to handle success.  Working some things in parallel, especially support tasks vs new features.


Leaders are focused on finding more customers, and keeping current ones happy.  Product delivery functions need to be automated, to allow tech staff to focus on what instead of how.  Customer service, support, operations and development tasks need to be centralized so that everyone can stay focused.  Knowledge needs to become somewhat portable so that team members can be added, back-fill others and cover breaks/days off.


Vulcan groups:

  • Place more premium on Time as money starts coming in

  • Need Repeatable processes that may still change often

  • Feel torn about moving key staff to bigger and better things

  • Start seeing many exceptions to what used to be simple processes


  1. Document Management & Wiki – Create a culture of portable knowledge early, and staff will maintain docs out of habit.  This makes it easier for players to switch positions, cover others during crunch times.

  2. Standups, Sprints & Milestones – Start to group tasks into small projects and track overall completion.  Allow different milestones to start competing for resources.  A first step toward portfolio management.

  3. Ubiquitous Search – Make it brain-dead simple to find that thing you saw a month ago, and share it with others.


Group 3: Prometheus


Things are really under way.  Founders may be somewhat disconnected from daily operations.  With monthly cash flow ensured, leaders begin to reach out to partners, competitors, upstream/downstream value chains, trying to expand customer base and/or find new features/products to add.  This phase usually includes the first serious wave of new hires who were not present at the founding of the org.  Cycle times get larger and more unpredictable as internal process and technical dependencies begin to weigh on the system.


Staying agile and responsive is even more important here than in previous phases.  Partners and competitors begin taking the product and company seriously.  This means real contracts, real accounts won and lost based on delivery.  At the same time, the heroes from Atlas phase are no longer able to touch everything every day.

At this point, the steering function has become as important to success as the rowing function.  Management needs to be able to see into the future, predict outcomes, plan for contingencies.


Prometheus groups:

  • Start to segregate knowledge to insulate groups from information overload and keep them focused.

  • Develop a strong need for metrics and measurement, instead of steering by feel.

  • Want standardized processes to allow for apples-to-apples comparisons over time.


  1. Robust Roles and Access Control – Organize things according to company structure, lines of business, etc.  Begin to control access by org and project membership.  Allow selected people/groups to collaborate from outside the company.

  2. Workflow and Audit  – As complexity and required quality levels both grow, more detailed workflow and audit trails are required to keep things moving quickly.



They Really Can’t, But You Can

Read this (now deleted) blog post by a dev at Oracle: No, You Really Can’t

There is so much wrong with that post.  But I’m in a hurry and don’t have time to put down 3000 words deconstructing Oracle’s entire business model and world-view.  Instead, I’ll just explain how we do the exact opposite.

GForge offers up the entire(*) code base for customers to examine, scan, and even change.  We maintain customer-accessible Git repositories (on, of course), so that customers have constant access to the current released version (that would be 6.4.1) and the version that’s in development, which we also deploy and use ourselves every day at

GForge customers can maintain their own Git repo (with, say, custom theme elements, or code to integrate with a custom database, or whatever), pull from ours, and keep up to date with new features, security patches and everything else we come out with.

As if that’s not easy enough, we also regularly send patches to customers to fix specific problems they report, even if they’re not at the current release version.  You don’t have to wait six months for the Oracle mega-patch, and get 3000 other changes you didn’t ask for.

Lastly, customers can (and are encouraged to) send us patches for things they have fixed or improved.  When Tony and I were GForge customers, we did this on a couple of occasions.  You’re welcome.

Every day, we try to treat customers the way we like to be treated.  Customer access to the source is just one reflection of that value.

PS – As if on cue, here’s a great example of why you don’t want to wait six months for the vendor’s bug fixes.

*Okay, okay.  There’s one file that we encrypt, that handles validation of the customer’s license key.  I know Richard Stallman is pro-actively spinning in his grave, but if you really want to see what’s in there, I’m sure we can arrange something.

GForge v6.4.1 Released

Today we are happy to announce the immediate availability of GForge Advanced Server v6.4.1.  This is a bug fix release that also includes minor enhancements.

Download GForge Advanced Server v6.4.1 Now!

New Features in GForge v6.4.1

  • Docman – We made a few updates to Docman in 6.4.1 including the ability to mass upload documents by uploading a single, compressed file (.zip, .tar, .tgz, .etc).  You can also quickly restore a prior version of a file to the newest version while retaining the complete version history.  Finally we’ve added better logging, particularly when files and folders are deleted so administrators can identify what was deleted and who deleted them.
  • Tracker – Project administrators can now manually add and remove user or user groups from monitoring a Tracker or Tracker Items.  Also any custom tracker fields can now be added to the “Quick Filter” when browsing Tracker Items.
  • Project Templates – Before 6.4.1 you could configure GForge to auto approve projects.  We’ve now added a better level of control by allowing site administrators to configure which project templates require projects to be explicitly approved or which templates can employ the use of auto approve.
  • Debian – We now support Debian “Jessie” in addition to the latest versions of CentOS and RedHat Enterprise Linux
  • Discussions – Images added to discussions in the “forum” view are now rendered in-line just as they are in “chat” view.
  • SSO & LDAP– We’ve streamlined the user experience for customers using SSO and LDAP

The Gory Details

GForge v6.4.1 includes a number of bug fixes and security updates. For the full details of this release, please have a look at the Complete GForge v6.4.1 ChangeLog

Download GForge Advanced Server v6.4.1 Now!

GForge 6.4.0 Released

Today we are happy to announce the immediate availability of GForge Advanced Server v6.4.0.  This is a feature release that also includes minor bug fixes and enhancements.

Download GForge Advanced Server v6.4.0 Now!

New Features in GForge v6.4.0

  • Sprints – GForge now ships with support for Sprints.  Agile shops can create sprints, manage tracker items within Sprints and track the progress of sprints via the burndown charts provided.  We’ve also updated the Tracker Query editor to support sprints.
  • Trove Improvements – We’ve completed revamped the user interface for managing projects within your trove and added some powerful administration features.
  • Project Templates – Project Templates are now a part of the Trove.  This allows larger organizations to divide their project templates in some meaningful way (e.g. by department)
  • Tracker Workflow – When setting up workflow GForge will now give each workflow status a visual indicator to the administrator letting them know which transitions they have setup up workflow rules for.
  • Added Support for CentOS 7 and RHEL 7.
  • Debian Support– We now support Debian Wheezy
  • modauthgforge – We enabled modauthgforge and use it by default when using SVN or Git over HTTP(S) which is a huge performance improvement.
  • pg-pool Support – If you have a separate server for the GForge database we now support pg-pool which implement connection pooling.  This will be a big performance improvement for customers using this sort of configuration.
  • Post-commit Filters – We now provide the same interface we offer for managing pre-commit filters for managing post-commit filters.
  • Training Videos – We have published a series of training videos on our YouTube channel

The Gory Details

GForge v6.4.0 includes a number of bug fixes and other improvements. For the full details of this release, please have a look at the Complete GForge v6.4.0 ChangeLog

Download GForge Advanced Server v6.4.0 Now!

GForge Next: Updated Screenshots, Kanban, Tasks, Chat

We recently gave an early preview of GForge Next which included a chance to sign-up for early access to GForge Next.  Today we are keeping the ball rolling by sharing new screenshots of our new Kanban feature, tasks and chat.  Please follow along as we share our ideas and you are encouraged to help us hit the mark by providing feedback either in the comments below or by sending a note to


These days Kanbans are a dime a dozen, however, what is unique about our approach is that we are able to provide the convenience of planning with Kanban without making significant changes to our current codebase.  After all, the Kanban is a more visual way to manage Trackers in our current system.  With Kanban we are leveraging that existing information and presenting in a way that makes planning easy:


The above screenshot hasn’t been implemented yet it gives a concrete idea of how we are approaching Kanban.  By default we will show all the statuses in your project as columns and inside them are tasks associated with each.  Changing the status of a task will be as easy an dragging a task from one column to another.  Taking things a bit further, you will be able to switch to a view that shows your tasks in a Kanban view grouped by the assignee:



For over a year we’ve made the case that chat shouldn’t be something you bolt on to your existing collaboration suite using a third party tool, and API and duct tape, rather, it should be an intrinsic part of any project.  While we’ve done this quite well in our current product, we’ve raised the bar by making chat available as you move in GForge from one project to the next:

GF Chat & Menu

As you can see in the screenshot above the project’s chat room is made available in a panel that you can hide easily.  GForge Next will support all the features our customers gotten used to in our current product including project activity (commits, updates to tasks, continuous builds, etc) with the project discussion.  If you look close, you’ll also see an updated version of the new menu in GForge Next that will let you quickly jump between projects easy.


Our current version of GForge has had bug and task management for years and we’re finally redesigning all aspects of how you work with tasks in GForge Next:


While this is a simplified version of what we plan on delivering, it shows the direction we are headed.  Gone is the old table-based tracker item browse and instead you get a simpler, more powerful replacement.  While browsing tasks you will be able to quickly change the most common field such as assignee, priority and status and once updates are made the page will reload the data to owner the selected filters.  Future iterations for browsing tasks will include some additional features:

  • The ability to edit a task right on this same screen.
  • Mass update of tasks
  • Searching and filters

Adding tasks has also been improved to be simple and clean:

Add Task

For existing customers, one of the things that should jump out at you is the tagging feature.  This has always been a part of our current offering but using tags has been cumbersome and thus, infrequently used.  GForge Next will make pervasive use of tagging.  As you start typing a new tag, we will give you an autocomplete list of matching tags that have already been used on your project.  Additionally we have made it much easier to add a number of new tasks with the new “Save & New” button that will keep you from having to go back and forth between browsing tasks and adding task.

We are exploring the idea of making this screen available as part of the browse page so you can add tasks without leaving the browse page.  Similarly we hope to have similar way for adding tasks when you are in the Kanban.

Again, these are just a few of the concepts we are working on in GFoge Next.  Let us know what you think by either posting a comment below or sending a note to In the meantime, stay tuned for more updates…


Get every new post delivered to your Inbox.

Join 1,632 other followers