An interesting post caught my eye this week entitled “Corporations and OSS Do Not Mix” by Ian Cordasco. It was kind of depressing – here was a person who had spent a lot of free time contributing to open source code, but the actions of some users of that code had taken the fun out of it.
My only issue with it was the targeting of “corporations” in the title. At OpenNMS we have a large number of corporate customers and we get along with them just fine. I want to talk about that in a bit, but first I want to address some of the other experiences Ian had that were similar to mine.
When I became the maintainer of OpenNMS back in 2002, I would often get e-mails from people that would start out with “OpenNMS is good, but what you need to do is …”. I used to spend a lot of time responding to them, pointing out that it was open source and anyone can help contribute to it, so they didn’t have to wait on me to do anything, but it never really helped and it turned into a huge time suck. I started to send back a generic e-mail that went along the lines of “OpenNMS is an enterprise product and if you won’t take the time to understand it then you should try something easier like Nagios” which would usually result in a reply calling me an asshole, but it took little of my time and then conversation was over. Now I pretty much just ignore them.
When you create something and share it, you are putting a bit of yourself out there and there are bound to be critics. For the most part they can be ignored, and you have to develop a thick skin to be in this environment. I’ve found that overall the good far outweighs the bad, and if you can learn to brush off the bad you can be very happy working in open source.
People tend to forget that open source “business” is still “business”. People exchange money in return for services. If I had Ian’s talent I would simply set up various custom development options, so when someone complained about a bug he could just return an e-mail with a price list. If you don’t have time to do it, make the prices really, really large – large enough that you would make time to do it. It’s your life – you are in the driver’s seat. I used to give a talk on running an open source business and I always stressed that you should never compete on price, or at least you shouldn’t lead with “my solution is cheaper”. Sure, open source software can provide tremendous savings over the life of the solution, but that doesn’t mean the solution itself is inexpensive to get set up. Done right, it will be better than any proprietary solution, but that doesn’t mean it comes without cost.
Always remember: free software does not mean free solution.
Getting back to dealing with corporations, like any interaction between two parties is it extremely important to set up expectations. You need to clearly outline what the product the client is buying covers (response time, 24/7 support, etc.). If they aren’t buying anything, then you don’t need to worry about them. I chuckled when I read “Well if you’re not going to take this seriously, we’ll have to start using another project.” We often get the “use another project” line and my response is “knock yourself out”. If you want to take this seriously, then pay me for my work. It’s like going into a free kitchen and complaining the soup is too salty.
A more difficult issue comes when someone wants to submit substandard code. This does require a little effort, since you can’t be sure that this isn’t just an eager but inexperienced coder versus someone lazy. Again, expectations are important. If you publish what the base level of quality should be, such as “must include unit tests”, then you can point to that when you don’t accept a submission. Plus, git makes it very easy to track a master branch and just apply your changes, so some sort of reply about how to do that could deflect criticism about the speed in accepting pull requests.
Ian makes a lot of really good points in his post, but I think he misses a point that if you run your open source project like a business then corporations (i.e. other businesses) will respect you and treat you like a business. We have one amazing company that just hired four (!) OpenNMS developers to work on code that they need. While some of it, if not most of it, will address their particular needs, all of it will be put into OpenNMS and they are paying us (gasp) to help project manage that team. That relationship did not happen overnight, but was built on a series of successful projects where we delivered particular value in exchange for money.
Look, I love, by and large, the open source community and I like being a part of it, but that doesn’t mean that open source and business are mutually exclusive. Learning to deal with open source as a business not only insures more open source gets created, but it also keeps it fun.
Free software doesn’t strictly imply the software is $0.00.
Ironic. From a product standpoint – even non-OSS products – Ultimately you get the same attitude. Folks tell you they need this feature or that feature and they want to know when it will be there. And they get bent when the feature is not justifiable or the wrong direction. Like there’s millions of Architects and very few deliverers.
And people demand these features especially when they could not develop things themselves. What sprint will I get the feature? (Really bad when they start trying to rearrange your sprints…)
And when you have a title like CEO or President, they want to grill you when they start pushing. (I have seen this in a couple of companies)
In many cases, they cannot articulate valid functional and non-functional requirements. For a few, very pertinent factors:
+ They haven’t done a valid architecture for their overall implementation. They have a list of products or are implementing tools.
+ They haven’t done their homework with regards to a data model.
+ They haven’t mapped out operational and engineering workflows.
+ They lack the concept of integrations and what it takes.
+ They haven’t mapped out and defined users and their responsibilities, functions, and personas. (Surprising how many organizations don’t have standard job requirements for folks that do the same thing.)
The really sad part is that all too often, the architecture gets dictated based upon political factors rather than operational or technical requirements. MBAs tend to make lousy Architects. They tend to manage by Spreadsheet and lack the technical chops to implement. Like a fantasy football QB. Great at calling all kinds of plays with players that may or may nor bear any resemblance to reality, and have never taken a snap or been rushed in real life. Reality is a bit different when sacked by a 6′ + Nose Guard that benches over 500, tilts the scales as 350 and runs a 4.4 40.
Many end up running 3 plays (budget cycles) and punting.
Products are Entities. They grow, expand, morph, change as they are used. Things need to be changed, fixed, added to, refactored, and expanded upon — All of which has been handled very well by the OpenNMS team and Community. (No so well at some of the others in the market!)