The Lasting Impact of OSS Communities

Before I jump into the meat of this post, I want to point out that I was stumped on exactly where to publish this. I mean, discussing how PHP and open source software has helped me certainly doesn’t belong on a corporate website, right? The more I reflected, the more I was convinced it belonged here. We don’t market GForge as a “PHP company” but it is and my ties to the company are as strong as my history with the PHP Community (phpc). So here we are and off we go…

So Ben Ramsey hit my twitter feed with his response to this post:

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

To help set the tone here was my actual response to Ben:

My relationship with PHP started around 1999 when it was still in its infancy, back when Zend was a new company, when MySQL didn’t support foreign keys and when installing Linux was relatively painful.  Back then the internet was all dial-up and I had a mini-tower PC running a version of Slackware that I literally peeled out of the back of a book on Slackware. In those days I was kidless and had just started my career and I wanted to learn as much as I could about things like Linux, Apache, networking and DNS. Being a software guy, it was a natural decision to try and setup my own website.

This day and age, all of that sounds ridiculous, doesn’t it? I mean it’s been a long time since I touched bare metal and if I need a blog, well, there are websites for that. Yet still, that decision set me on a path that I would have found unbelievable back then.

With the server setup I wanted to find an open source CMS solution and stumbled on Geeklog. Geeklog is an open source, LAMP-based CMS and at the time was lead by Jason Whittenburg. I’ve learned that open source projects are really about relationships and it wasn’t long after meeting Jason that he had me making contributions to the project before eventually handing me the project a few years later. During the next decade or so I had the chance to learn how to run an open source project and, just as important, I learned how to leverage my work professionally. How exactly?

Probably the most frivolous was I started and sold an outdoors-based community website running Geeklog. This proved to me that I could build something a company valued enough to buy it but more importantly it proved that PHP was maturing and was nearly ready for primetime.

Fast forward to 2003, I took a position in State government to help lead software development. Everything our team built was in Java and IBM DB2.  Development was slow, you couldn’t run both Java & DB2 on workstation hardware back then which meant the development feedback loop was painfully slow. Thankfully I had bosses that “got it” and by about 2005 we deployed our first LAMP-based system to production. As much as I’d like to take credit for the change, Facebook’s launch put PHP into the spotlight. It was then that I recall seeing legitimate jobs for PHP’ers and software consulting firms that could find us PHP resources to augment our team. Around the same time PHP conferences started popping up not only giving the phpc a voice but allowing someone like me, in Iowa, the chance to meet many of the great people who have influenced me over the years.

While all that was going on with my work in State government, we were constantly improving our software delivery processes and tools. We went from VisualAge for Java and ClearCase to a workstation running CVS and Bugzilla to buying GForge. Back then, GForge just made the shift to a commercial-only license but we got the source code, mostly PHP, and over the years we provided a number of patches back. All of this lead to the opportunity for me to buy GForge. That opportunity was a classic case of “luck favors the prepared” but I can say my experience with Linux, OSS and the phpc made this possible.

The takeaway I want to leave you with is simple. The value of the any community is in the relationships you form. Strong relationships in the phpc can help you with more than Building Better Software. Those relationships can open up future opportunities both professionally and personally.  So while I haven’t been active in the phpc, it is still a part of who I am, a part of this company and this serves a reminder that I need to rekindle some of those relationships. To that end, I’d love to hear from others like me to tell their stories and encourage others in the PHP and Open Source communities.

 

The Loveless Start Up – IPO Trough

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

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

 

 

 

 

 

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

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

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

I want to leave you all with just three thoughts:

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

 

GForge v19.0 Released!

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

Download GForge v19.0 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Highlights in GForge v19.0

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

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

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

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

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

  • The v19.0 ChangeLog will help you understand the changes you can expect.
  • The GForgeNext FAQ will answer most of your questions but don’t hesitate to send additional questions.
  • Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.

Download GForge v19.0 Now!

GForge and Open Source Software

Old School OSS

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

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

Today’s OSS

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

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

GForge and OSS

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

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

GForge Going Forward

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

Learn More about GForge Take a Tour

Download GForge or Host a Project with us

 

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.