Category: Uncategorized

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

 

Securing GForge on Apache httpd Server

It’s a series of tubes, you know.

Secure connections are integral to keeping your important information safe, on the Internet or your private company network. For years it’s been fairly simple — turn on SSL, buy a certificate and let the browsers ensure that your data stays private. Unfortunately, it’s no longer that simple.

Over the last 15 years, computing power, virtual servers and good, old-fashioned software bugs have all conspired to make much of the encryption plumbing from the last 15 years obsolete. In fact, it’s very likely that if you’re running Apache httpd and mod_ssl, you’re allowing protocols and ciphers that expose your server (and your data) to needless risk of compromise.

Note: If you’re a customer, and GForge Group manages your server, these security updates are already in place. Get in touch if you have any other questions.

Check Yourself

It’s actually pretty easy to test your system, and it can be done in production, without affecting your current users.

For servers that are on the Internet, you can use an online scanner. Here’s SSLLabs, from Qualys:

https://www.ssllabs.com/ssltest

Enter your site’s URL and click Submit. After a minute or two, you’ll get output like this:

SSLLabs Scan Results (yikes!)

In the report details, you will find explanations of anything marked as a problem from your server, including how to close security holes that were found.

If your server isn’t on the Internet (i.e., on your internal network), then you’ll need to download and run scanning tools yourself. Here are some popular ones:

  • TLS Observatory — An open-source scanner from Mozilla, written in Go. You’ll need the Go runtime to run this on your server or desktop, or you can use the Docker image. Performs scanning for both the SSL/TLS version and cipher suite(s) in use.
  • Cipherscan — Another tool from Mozilla, written in Python.

Get With The Times

After running your scans, you’ll need to decide what changes (if any) to make to your SSL configuration. It’s important to understand that choosing the most up-to-date settings will leave out some older clients. Fortunately, Mozilla also has a great online tool to help you balance security with compatibility.

https://mozilla.github.io/server-side-tls/ssl-config-generator/

Give this tool your current version of Apache httpd and OpenSSL, and you’ll get various choices for maximum security versus maximum compatibility.

Our Recommended Configuration

In the end, we went with the Modern configuration, but added the AES256-SHA256 cipher back to the list. This allows only TLS 1.2 (the most secure), but adding that one cipher back keeps compatibility with older non-browser clients like curl, so that existing SVN and git over HTTPS are not broken.

Here’s the configuration snippet we recommend for GForge servers:

<VirtualHost *:443>
    ...
    SSLEngine on
    SSLCertificateFile /path/to/signed_certificate_followed_by_intermediate_certs
    SSLCertificateKeyFile /path/to/private/key
    # Uncomment the following directive when using client certificate authentication
    #SSLCACertificateFile /path/to/ca_certs_for_client_authentication

   # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=15768000"
    ...
</VirtualHost>

# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite AES256-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)

Signs That You’ve Outgrown Github, Part 3: Merges

This is part 3 in a series about the limitations of Github, and how they might be holding your team back from its full potential. If you want to go back and catch up, here’s Part 1 and Part 2.

Go ahead, I’ll wait right here.

Done? Okay, let’s move on.

Today’s discussion is about getting code merged. It’s one of the most fundamental things any software team has to do. If your team is anything like ours, it’s something you do many times every day. It might even be the kickoff for your Continuous Integration/Delivery process, as it is for us.

Reliable merging is the key to getting multiple things done at once

Getting things out quickly is important, but preventing outages from bad code is even more important. You probably want an easy way to review and even test code that doesn’t distract too much from the work you’re already doing.

Once again, Github has a wonderful system for promoting code from one repository or branch to another — the Pull Request (PR herein). In particular, the PR is great for open-source projects where people might want to contribute, even if they’re not members of the main project. The proposed contributions can be examined by the main project member(s) and be pulled in only if they’re helpful.

Typical Github pull request — you can see the code changes and their purpose, all in one place

But like many other Github features, you may find the PR process to be mis-aligned to your needs, in a way that creates a little extra delay and a bit of confusion every time you use it.

Pull Requests 101

For those who haven’t tried one yet, a pull request (PR) is a special kind of task, asking someone to merge a set of changes (commits) from one place to another. In more general terms, you can think of it as promoting a chunk of work from one level to another — such as from a development branch to test and then to production, or from a hotfix branch to long-term-support.

A simple example of promotion — taking a specific change from one environment to another

Because it’s a request, it doesn’t involve any access to the project repository from any non-members. The project team can review the proposed changes and take them, ask for revisions, or ignore them. It’s a great model for open-source or otherwise loosely-coupled groups to share ideas and improvements.

Keep It In One Place

But that flexibility comes at a cost. Pull Requests are opened and managed separately from individual tasks, so you’re basically creating another task to review each task’s work. The open or closed status of each task can be independent of the status of the related PR. Additionally, there’s nothing stopping someone from submitting changes for multiple tasks in one PR, which can be confusing and difficult to review.

For software teams that aren’t open-source, this loose coupling actually creates more process, more overhead, and time thinking that could be spent doing instead.

Ask yourself — wouldn’t it be a lot easier to merge the code as an integral part of the task itself?

Singularity Of Purpose

Let’s start with an assumption — that in order to change your code, there should be a defined reason for doing so.

You’re writing code because something needs to be added or fixed. There’s a use case. A story. A bug. A feature. A customer who wants something. There’s a reason to change what you already have.

You probably also want to do two things with your tasks:

  1. You want to create a plan ahead of time, for which things will be done, by whom, in what order.
  2. You want to keep track of progress as things move along.

Once you start depending on tasks for planning and tracking, you can begin to improve your overall process, reducing the number of steps and the distance between idea and working code. As you do, separate PRs may start to lose their appeal. Asking developers to open a separate kind of ticket to get code merged is a hassle. Allowing them to put multiple bug fixes into one merge is asking for confusion and mistakes.

If you’re delivering code using a well-defined workflow, PRs can actually cause problems:

  • Audit trail — It’s difficult (or impossible) to know later which code changes went with which task.
  • Larger merges — the code review itself becomes much more complicated, since there are more commits, more changes files.
  • All or nothing — If you like the changes for task #1, and for task #2, but there are problems with the tests for task #3, the whole PR is sent back for rework. This means you’re likely sitting on changes for longer.
  • More conflicts — Pretty simple math: (Larger merges) + (All or nothing) = More conflicts.

Since there’s no way in Github to limit the content of a PR, there’s no good way to prevent this kind of behavior. Creating a PR for every single bug becomes a tedious time-sink that doesn’t add value to your day.

Now, you might argue that a Github PR can act as the task itself, and it does — but not really. PRs are only retrospective, meaning that you create one after (or while) doing the work. If you don’t create tasks before doing the work, then you’ll never have any way of planning or tracking progress.

Simplify, Simplify

For most teams, the overlap between tasks and PRs is additional work that doesn’t generate any value. What you really need is a way to automatically detect code changes, review those changes and then promote them to dev, test and production, all as part of the task.

This kind of integration means that you can go back to the task later, understand the intent of the change, and also see the code changes that went with it. Your task tracking becomes a source of institutional memory, so that people can move in and out of the team, or across different features without making old mistakes over and over again.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come try GForge Next for simple, comprehensive and elegant collaboration.

Signs That You’ve Outgrown Github, Part 2: Task Management

In my last post, I introduced a set of features (and failings) that might have you wondering if Github can grow with your team. In this post, I’m talking about tasks, workflow and keeping things moving.

Github’s Workflow Is Simple And Cool

When you’re starting out, Github’s approach is really helpful. You can create a task with just a summary sentence. If you want, you can add a more detailed description and some labels.

Tasks are open or they’re closed, and you can close a task with a commit. From a developer’s perspective, it’s wonderful to grab a task and write some code, then update the task without having to visit the website. You get to stay in your IDE, your command-line — whatever tools you’re using to do the work.

The Real World Gets Complicated

These features work very well for teams that are just starting out, and for projects that may have somewhat disconnected participants (e.g., open-source projects). But as your team begins to deal with marketing, sales, customers, or even other dev teams, you may rub up against some important limitations.

There’s more to life(cycle) than Open and Closed

Very often, there are other pieces to your workflow than just coding. There could be planning, design, code review, testing, deployment, and other activities. It’s pretty common to reflect some of that workflow in the status, so that everyone can tell where a task is and what needs to be done next, without having to re-read then entire history.

Closing a task just because you’ve committed some code assumes that everything else will go right. Usually, committing code is the beginning of the process, not the end.

Not everything fits in the same box

Not everything is a task to be done in the code. Sometimes, you want a place to flesh out a user story, or discuss the design for a specific page. Maybe you need to track servers, or which customers have which version of your product.

You might be able to jam these different kinds of information into a Github task, but it ends up being a bigger version of the labeling problem from my previous posting.

What’s going on?

Github has some pretty decent release/milestone tools, and you can group tasks into a milestone to track overall completion. That project-level view can be great, but what about planning and tracking your current sprint? Or planning and tracking your own day?

Standups get a lot easier when you can automatically see what the team worked on recently, and when the team can identify what they plan to work on.

What’s really important?

This is one that everyone runs up against pretty quickly. Putting a priority on each task allows the team to keep moving, by knowing which tasks to work next. Without prioritization, everyone’s just guessing about what is most important.

Github has no way to prioritize tasks. Even if you use a label (to beat a dead horse), you won’t be able to sort them.

Plans get tangled up

It’s pretty easy to enter and manage tasks in Github, and depending on your level of detail one task might be completely stand-alone from another. Almost inevitably, though, a task will be blocked, waiting for some other task to finish. Your new web page needs an API update from someone else. A customer’s support ticket might be waiting on a bug that someone is working on. Or a use case can’t be complete until all three web pages are working together.

The ability to manage dependencies has been asked and discussed many times over the years, and Github just doesn’t want to take on the complexity. It doesn’t have to be a Gantt chart, but making sure that everyone knows when tasks are blocked (and when they become unblocked) is key to maintaining project momentum.

A More Realistic Approach

First off, don’t expect Github to change. The simplicity of their task management is perfectly suited for many, MANY projects. It’s easy to get started with, and is a great place for sharing open-source and personal projects.

But maybe your team has started to suffer from that simplicity, and you’re looking for something to fill in the gaps that Github leaves. You might even be tempted to try one of the dozens of “bolt-on” tools that claim to integrate tightly with Github.

Instead, let me suggest that what you really need is something that was built from the ground up to start simple, grow to be comprehensive, and stay elegant. Something that’s easy to use, but allows more complexity as you grow into it.

Here are a few more simple pieces of advice:

  • Instead of shying away from adding different status values, be honest about the workflow you want and make the tool serve your needs.
  • Consider that maybe you need a different set of fields for tracking use cases or UI designs, versus coding tasks, versus customer support.
  • Don’t settle for something that’s too simplistic, or a patchwork of loosely-coupled tools, when working around their limitations will cost you time that’s better spent on your actual mission.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come back soon for another sign that you might have outgrown Github .

Come try GForge Next for simple, comprehensive and elegant collaboration.

Signs That You’ve Outgrown Github

Github is WONDERFUL. I have used it for a long time now, and it’s great. It’s easy to get started, and especially for one-person projects, it really helps keep things organized.

But as you start to add team members, competing priorities, and overall complexity, something changes. In lots of little ways, Github starts to show that it just wasn’t designed for long-haul software projects, with many team members and a non-trivial workflow.

Here are some of the things you might already be dealing with:

  • You’ve created so many labels that you’ve written a wiki page to tell everyone how to use them (and how NOT to use them!)
  • Maybe you want to keep track of bugs and support tickets separately.
  • Perhaps you don’t think that developers should be able to close a ticket just by committing code.
  • Maybe you’re tired of having to search in Google Docs, Basecamp, Slack and Github to find where you talked about that new feature.
  • Could be that you need to manage the relationships between tasks that depend on or block each other.

I’ll do a blog post for each of these topics. This week, let’s start with the first one — labels.

Labels

Labels are quick and easy to use, offer a lot of flexibility and require virtually no setup or configuration overhead. The default labels in Github look something like this:

Those are probably fine for 98% of new Github projects. Over time, however, most teams will expand on the list of tags to include different values than the default list, and even different types of data. Adding categories for basics like type, priority, and status makes a lot of sense when you’re managing a backlog. But all of those new values expands the list beyond what you can keep straight in your head.

So, how can teams use complex label sets reliably? One common convention is to use a prefix word to identify the group to which each label belongs (courtesy of Dave Lunny):

This approach has the benefit of including the type of label as part of the label text, so you won’t be confused between “Status: Test”, “Environment: Test”, and “Task Type: Test”. Visually, the various colors can be used to show differences in the specific values, like production vs non-production, or high priority vs lower priority.

The downside is that when viewed across label types, the different colors are confusing and even downright jarring. Instead of quick visual signals based on color, you actually have to read each label value. It’s bad enough when looking at a single task, but when browsing a list of tasks, it can be a hot mess.

Another approach is to use similar colors for grouping. Here’s an example (from robinpowered.com):

While it’s much easier on the eyes, you no longer have the label type included with the label value. Also, this particular set of labels combines and separates a lot of values in ways you won’t appreciate later — for example, why is the production label in “Problems” and not “Environment”? There’s likely information on a wiki page somewhere, explaining that you don’t choose anything from “Environment” when it’s a production issue, right?

This next example isn’t really an example at all, but a cautionary tale. Imagine walking into your first day with these guys:

This isn’t someone’s drug-addled fantasty project, either — it’s servo, a very active and popular project on Github.

Tools For Your Tools

In response to this widespread need, there are actually tools (like git-labelmaker) dedicated to helping Github users automate the creation and management of complex sets of labels, using different naming conventions, color schemes and labeling styles. Which is very cool — except that it seems like an awful lot of work to go through, doesn’t it? If someone has created a tool to help you use another tool, maybe it’s the wrong tool.

Tag/label functionality was never designed for complex values or workflow.

A Right-Sized Solution

Instead of a mashup of various labels, organized by a prefix word or a color scheme, consider this layout (with a few additions that are, IMO, obvious):

Separating these various concerns also allows you the flexibility to require some fields when a task is created, and wait for the right step in your workflow for others. Instead of manually enforcing your task management process, you can allow your tool to do it for you.

One last benefit — if you’re using separate fields instead of specific tag values, then changing the name of the field or the values over time won’t break old data. The new field name or value(s) will be reflected in older tasks automatically.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come back soon for another sign that you might have outgrown Github — next time, we’ll talk about Github’s one-dimensional task tracking.

Come try GForge Next for simple, comprehensive and elegant collaboration.

How Many Project Tools Do You Really Need?

In my last post, I talked about some criteria for choosing between all-in-one or best-in-breed tools. Now, I’ll apply those criteria to our product space, and try to show why a unified team collaboration tool makes more sense than what you might be living with now.

So, let’s imagine that you’re looking to solve the following problem: How can we get everyone rowing in the same direction?

By “everyone,” we mean executives, product owner(s), designers, development staff, customer service, maybe even customers themselves.

And by “rowing,” we’re talking about all of the things it takes to get your product to the customer — things like planning, design, coding, marketing, testing and support.

The Accidental Integrator

The worst-case scenario is also the most common — each discipline area adopts whatever tools appeal to them.

NB: This is a simplified version of actual events from a previous job. The details have not been exaggerated, and the people involved were otherwise very capable, smart, and successful.

  • The Product Owners all decide to use Trello, and thus force it on the development staff.
  • The designers prefer Basecamp, where they can organize screenshots for the various user stories they’re working on. This means that the Product Owner has to look there as well, and so do the developers, and possibly also the customers.
  • The developers decide on Github, since it’s easy to start and Git is pretty awesome.
  • Customer Support starts a wiki, so they can get all of their procedures and help scripts in one place.
  • They already use FogBugz for tracking customer issues, and neither Trello nor Github has the features they need. This means that the Product Owner and developers have to look in FogBugz almost every day, as they respond to problems reported by customers.
  • The executive staff needs all of the above to keep a handle on what’s happening where. They also create and manage a couple of spreadsheets in Google Drive, to keep summary data for the various projects that are in process, and to prioritize upcoming work.

Here’s what that set of tools ends up looking like:

Pretty, pretty arrows.

Of course, some of these tools can be tied together with vendor-supplied integrations, web hooks, or some simple scripting. Adding these integration points might make things more convenient for users, but it doesn’t change the overall picture:

Now with 20% more arrows!

Inevitably, some amount of developer time each month (or week) will now be spent troubleshooting why x is no longer taking to y, and fixing it. People also regularly forget which password goes to which system, and need resets on a recurring basis. [Ed. This happens to me ALL THE TIME.]

Regardless of how good those integrations are, everyone still has to search across two or three or more tools to find what they’re looking for.

Each tool you add is another silo of data and process, and more friction in the overall workflow.

A (Kinda) Integrated Solution

Many teams opt for the Atlassian/Microsoft/IBM approach — buying a set of tools from the same company, with the promise of tighter integration. It’s sold as an all-in-one solution, in as much as you’re buying from one vendor. And for the most part, that’s true — until it’s not.

Tool suites like these do a much better job at tying related data together — build status can show up in the related tasks, support tickets can reference wiki pages, chat can become your company’s heartbeat. All of those capabilities help to decrease friction, distribute knowledge, and keep the entire organization plugged in to the right priorities.

Oh, that’s much simpler. (source: ClearVision)

But they’re still separate tools. You still have to flip from one app to another to search, get the details, or make updates. Each tool is still deployed and managed in separate software versions, which (sometimes) fall out of compatibility with each other. And don’t forget that you’re still going to pay licensing and maintenance for each tool. Even at a bundled rate, you’re probably getting soaked.

Half-way integrated is better than the patchwork quilt approach, but it still creates implicit silos of data, and introduces other hidden costs. It’s like being half-way delicious.

The Whole Enchilada

Speaking of delicious, what happens when you *actually* integrate tasks, wiki, chat, releases, documents, source code, support, and continuous delivery? If you could get all of these chunks of functionality in a single system, how would it affect your experience and productivity?

Isn’t that so much simpler?

There are some big benefits:

  • A seamless experience for managers, development staff, creatives, support and even customers to get involved in.
  • A single source of truth for what’s important, what’s done, and what’s next.
  • One place for your institutional knowledge to live on. On-boarding becomes easy. Hard-won company wisdom doesn’t disappear when someone leaves or changes roles.
  • One search box that is deeply connected to all of your projects, source code, documents, information, tasks and discussions. Find a specific key word or error code no matter where it’s hiding.

There are lots of situations where best-of-breed thinking makes sense. In areas where a specific tool improves your productivity, saves money, or just makes work more fun, it can be worth it. If the need you’re filling isn’t central to your business, then it’s not a huge risk to try (and maybe abandon) something new. But that’s not what we’re talking about here.

The way your team organizes and works together is possibly the most important and valuable part of your entire business. Trying to run things using a patchwork quilt of point solutions might seem cool at first, but it’s probably not where you want your team spending their time.

That’s why we built GForge. Because we do what you do every day, and we think it should be easier.

Come try GForge Next, and let us know what you think.

Note: My editor wanted me to include email as part of this discussion, but it added way too much to the article. GForge does some great things with email, and I will publish something soon to show how and why.

The Weekly Forge: 10/07/2016

The biggest development this past week is work on GForge AS v6.4.3 has started and we anticipate having it available for current customers by the end of this year.  Obviously we’ll continue work on GForgeNEXT which is accurately reflected in the highlight from last week below:

  1. Git Server Side Merges – Right now server side merges work between any two branches except when the destination branch is master. Turns out the is a bug with Git itself and we already have a patch from the Git development team and we’ll continue testing that out.
  2. Continuous Integration – We’ve begun designing the mocks required for building a Continuous Integration dashboard for all GForgeNEXT projects using Jenkins. This will complete our vision of making the integration between GForgeNEXT and CI systems tighter which reflects how integral they are to software teams.
  3. GForgeNEXT iOS – The first view for the GForgeNEXT iOS app has been stubbed out and work will continue over the coming months.
  4. Dependency Management – When a ticket has predecessors (i.e. blocking dependents) when those tickets are taken care of GForgeNEXT will notify the assignee and submitter of the ticket that work can begin on that ticket.  Those notifications will happen with growls which are also sent via push notifications via Adroid/iOS application. This is a big step towards helping PMs and project leads with automated dependency management.
  5. Improved Link Handling in Docman – Currently in 6.4.2 and prior the links to documents in docman explicitly ping to the most current version (i.e. version 7). The problem is if you email that or include it in a ticket or wiki entry that version may eventually be replaced with newer ones.  We’ve made it so the links in docman will always give users the most current version.  Don’t worry you can still explicitly send the link to a specific version of a file if you want.
  6. A handful of bug fixes for v6.4.3 are being actively worked on.

GForgeNEXT Update for 9/30/2016

Beginning this month our team will be giving weekly updates on the GForgeNEXT development.  This won’t be the painful details just the good stuff boiled down to a few talking points. We should be clear that GForgeNEXT is in open beta at https://next.gforge.com so sign-up today! Before we give our first update we’d like to share what exactly where GForgeNEXT sits.

  1. Teams – You can invite new or existing GForgeNEXT users to your projects.  When you do so, you pick their role and once the invite accepted they can begin collaboration.
  2. Tickets – plan and distribute work across your team.  We honor existing workflow rules, however, administration of those rules doesn’t exist yet. Browsing and filtering of tickets works just fine.  In short while some admin function do exist yet the ticketing system is working well for day-to-day use.
  3. Stand-up Report – GForge provide each project with a stand-up report. See what each team member has accomplished, what they are working on and what they plan on working on.
  4. Git Support – Browse branches, tags and commits through the UI (merges and merge requests are under development).
  5. Continuous Integration – Our new Jenkins plugin uses the latest Jenkins release which will pave the road for new features. Right now the Jenkins plugin accurately reports build activity back to the GForgeNEXT project and this is fully tested and working. Future work will include building a CI dashboard in GForgeNEXT.
  6. Android Support – Access chatroom and tickets all while getting push notifications while you are on the go. (iOS application is under development).
  7. Language Support – GForgeNEXT will eventually support multiple languages.  Right now we support Spanish and English and the language is set based on browser preferences which is nice for new users.

Update for 9/30/2016

  1. Git – Server side merges is code complete and being tested internally. Once this is done we will move right into merge requests.
  2. Notification Center – this feature is similar to what you see on social media sites like Facebook. This week we are adding additional formatting to notifications (date of notification and project it was generated from).  The posts are also now navigable, taking the user to the proper artifact (i.e. ticket, chat, etc)
  3. iOS App – Development began last week.
  4. Responsive UI – We’ve been doing testing to ensure GForgeNEXT renders and functions properly using the small displays on mobile devices.  The only area giving us problems was the mega-menu (the main way to navigate projects on the device)
  5. Tickets – We’re making dependency management a key feature when working with tickets.  The search API for tickets in GForgeNEXT had to be expended to make this possible and we’ve updated the interface to make this as slick as possible.  We will be sure to call attention to any ticket you are viewing that has dependencies.

As always we welcome questions on any of the activity you see.

Join Us at HackISU this Weekend!

This weekend The GForge Group will, again, be sponsoring HackISU this weekend up in Ames.  This is a great opportunity for young developers and engineers to have fun and gain experience working with technology. For our part, we are awarding $750 per team member (up to $3,000) to the team that makes the best use of the GForgeNext API. This is similar to our award from last year but unlike last year we trying to encourage creativity by not giving specific ideas on how to use our API (nor how you might integrate it with other APIs).

So have a look at the GForgeNext API documentation, read our intro to the GForgeNEXT API and let your imagination roam.  Any questions you may have ahead of HackISU this weekend can be sent to feedback@gforgegroup.com.

Meet the GForge Team: Kyle Goranson

This is a big year for GForge Group — we have redesigned our flagship product, GForge As, and are relaunching it as GForgeNEXT. This Spring we announced that NEXT is now available in free, private beta. Behind the scenes our team of developers has been working many long hours to bring this new product to market. Over the rest of the summer, we will be posting a blog series entitled “Meet the GForge Team.” In this series will be spotlighting each member of our team, their backgrounds, roles, and unique perspectives, so you can get to know the faces behind the software at GForge.

Summer is in full swing and it’s apropos to kick off this summer series by highlighting our interns.

Kyle Goranson
Intern, GForge Group


Where do/did you go to college?
Coe College

What is/was your major?
Computer Science, Mathematics, and Physics

When did you learn to code?
My first formal coding experience (also my first reasonable language) was my computer science 1 class in my Sophomore year of college in which I learned on C++. But my first coding experience was creating programs on my TI-84 calculator in high school, which I figured out myself, and looking back, programming in TI-basic was absolutely horrible.

What is your favorite project you have developed?
I’m going to have to go with a group project that spanned a full semester which was building a class registration system in C#. But it’s not the main part of the assignment that makes it my favorite. My group was fairly far ahead so I decided that our registration system would be better if it had a retro arcade hidden within it. So I wrote Pong, Snake, Space Invaders, and Pac Man. All of which I made as close to the original as possible. To get to the arcade, on our login screen you needed to enter your username and then enter the konami code instead of your password.

What are you doing at GForge?
I am primarily working on developing an Android app for GForgeNEXT, and I am also expanding test coverage.

What attracted you to work for GForge?
I worked with Michael Tutty during HackISU where I was building an app that was integrated with the GForgeNEXT REST API. I really enjoyed the interactions I had with him.

What is your typical day like at GForge?
The first thing I do is check to make sure my queue is up to date and then join the standup. When the standup is done, I will move on to working on whatever I have for the day. When I run into issues I will ask a question in chat and this will sometimes turn into a hangout where we figure out the problem. Somewhere in there I will take a break for lunch.

What is your dream job?
That is a good question. I have no idea. Definitely something involving programming though.

When you’re not working where can you usually be found where? Doing what?
I can usually be found at my computer even when I’m not working. I will often be playing an online game with friends, the most common of which is League of Legends.