The Open Initiative

As an organization, we’ve always been pretty transparent about our company and culture; we even post our employee handbook online, for all to see.

Free and Open Source

After offering express (free) editions of our products, and open-sourcing all of our extensions, we’ve warmed up to the idea of “free and open source” software as a business model. However, in order to remain viable as a software product company, we need to balance “free and open source” with “getting enough people pay us so we can do this as a full time job.” That’s not easy.

Core Products

Our core products’ code is not open source. Not because we’re secretive about things, but because that’s just how it’s always been. But it’s not simply good enough to take all of our code and move it to GitHub… even if that weren’t a time/resources hurdle in the first place.

We are not prepared to accept your change requests.

Our coding guidelines are not at all documented, our development and testing processes is not open, and a detailed roadmap is not published. It would be quite discouraging to reject well-thought out merge requests for what appear to be arbitrary reasons.

We need a new software model.

Nearly all “open source” companies have proprietary versions of their open source software that most enterprises “must” buy in order to make the product viable for their use case. This is somewhat frustrating, not only because users can’t be sure when the source code will actually be available, but because transitioning from the free to the proprietary versions can be a bit challenging technologically.

Our “express” editions are have a similar business model: they lack important features that most enterprises “must” have. Technologically, the enabled features are controlled by a license key, which means that switching between free and paid is a breeze: just swap the license key.

However, if we were to simply open source our existing software, then all you’d need to do is “comment out” the edition checks, or even easier… just edit the “IsEnterprise” property to always return “true”. We could try to prevent that with a restrictive license agreement, but that might be difficult for the community.

Perhaps… a hybrid model?

Currently, customers with a perpetual license can download an archive of the source code from our MyInedo portal. Some customers have found this quite helpful in identifying why the software is behaving in a certain manner.

In the near future, we want to allow our customers to apply for access to our GitLab-hosted repositories. From there, they’ll be able to much more easily comment-on and identify behavior in the code.

Open Change Management

We’ve moved our core product changes from an internal JIRA instance to a cloud-hosted YouTrack instance. This allowed us to enable “guest access” for browsing the actual issue tracker we use internally for managing changes to our software products.

Of course, we also use other tools to manage priority and determine scheduling: instant messaging, impromptu meetings, whiteboards, scraps of paper, six-o-clock scotch, and notecards. These aren’t quite that easy to open up, which means we’ll need to improve our internal process as well.

Open Roadmap

In order to open our roadmap, we need to have a roadmap to publish. Our current system of planning with whiteboards, sticky notes, and cellphone pictures of those boards aren’t quite sharable with anyone who didn’t attend those meetings.