Open Source Bridge

Open source has moved from experimental to mainstream in the past 10 years, but has definitely changed the landscape in the last 15 years. Because of that, we have a few generations of people within the broader ecosystem, and they probably have no idea that all of these communities exist, much less the fact that there's a whole ocean of a open source technology industry out there.

Team dynamics are tricky. They're different when you're volunteering your time, when you're working for someone, or when you're trying to build something and invite someone else to build other good things too.

We ask for a lot of things under the heading of 'project management'. This leads to pain and suffering when we are not clear for what we are asking for, or we're not set up to support what we're asking for. This is particularly special in open source companies and projects.

Tricky to master. Sometimes the last thing you care about. (Let me code already, dammit.) However, a small amount of work on your sales-fu will pay off. So let's do this thing.

Creating functional requirements as a part of the planning process is like creating a treasure map. You want to get compensated for the value your cool built-with-open-source-thing is providing to your clients. Your clients want it to work better than what they originally had in mind. If you do the work upfront, you'll know when you've hit the X marks the spot.

Open Source is great fun, even in the area of professional services. But sometimes, you want to be able to pay the bills with your awesomeness too. One of the areas of difficulty is setting boundaries with clients, even though you really just want to write amazing stuff.