10 reasons why commercial companies should do open source software

  1. Positive PR
  2. External targeted contributions. For example, most people submitting patches to open source software are facing some issue as a user. If they are experiencing an issue, others may also be experiencing similar problems. This is a much better way of driving development, compared to doing it post expensive market research.
  3. Marketing
  4. Recruiting vehicle
  5. Increasing the size of markets. For example Google is trying to bring more people online with Android to increase the size of search market.
  6. Commoditizing complements : http://www.joelonsoftware.com/articles/StrategyLetterV.html
  7. Reducing the cost of training new employees
  8. Influencing the direction of an industry. For example setting standards for server hardware with Open Compute Project.
  9. Free testers
  10. Improving employee morale

Ten pieces of advice to managers of software companies; from a programmer

How would you want manage a software company ? Software is unlike many other industries in the sense that it is a creative process. In other industries ( say a Coca-Cola bottling plant ) there is a linear relationship between labor and result. If it takes 1 hour for a person to fill 100 Coca-Cola bottles, it will most probably take him 2 hours to fill the a total of 200 bottles and so on. If you want 200 Coca-Cola bottles filled in an hour, you should therefore employ 2 people. It is fairly predictable how much time it would take to fill 300 Coca-cola bottles with one person : 3. None of this translates well into software. In software, once a software is developed, it is trivial to create a copy of it. Software companies make money by making new things : adding features, fixing bugs etc ( I am excluding SaaS business models for the moment, though they also require new features to stay on top of competition ). One important feature of this type of creative work is that, by its very nature, it is unpredictable. If you know what code will solve your problem, and you know that it will work, typing in the code is the simplest thing in the world. Majority of software development involves figuring out how to solve the problem. And this process is venturing into the unknown, taking educated guesses, trying what works and on failures start fresh. What kind of management does this lend itself into ?

First off, it is pointless to ask people to put more time at work. When you try something and fails, it is important to take a step back and relax. The problem needs to be emptied from your mind for a while so that on the next approach you will not go down the same rabbit hole you went before. Software companies that require employees to put their bums on their seats as much as possible needs to go out of business, and fast.

Secondly, it is very hard ( and most times, impossible ) to estimate how much time it would take to do something. To give you an example, lets say I want you to make me some “Japanese Kuhoo Kuhoo”. I won’t tell you what it is, or how to make it, but I want you to tell me how much time it would take to make it. You don’t know what you would need to make it. You don’t even know if it is a real thing or something I made up entirely to mess with you. How will you know how much time it would take ? You can’t. You can’t plan for the unknown. If you absolutely want to know how much time it would take, please consult an Oracle. Because their estimates can have as much bearing on reality as anyone else’s.

Thirdly, you must never reward drama. Drama is always a sign of dysfunction, not capacity. Imagine two teams. Team 1 is a well run team. There are unit tests for almost all important functionality. Commits that break unit tests are disallowed automatically from nightly builds. Team 2 gives zero fucks to any sort of automated testing. Result is that days before release, testing reveals lots and lots of bugs. Developers are asked to stay back late to fix issues. Management sees that Team 2is toiling away, burning the midnight oil while people from Team 1 goes home on time. Management rewards Team 2 with bonuses. Until of course the house of cards built by Team 2 just crumbles under its own weight.

Fourthly, and this is not specific to software companies. Accountability should never get lost in layers and layers of management. For example, imagine people found critical security issues during testing just before release. Management is not supposed to say ‘We will focus on these trivial stylistic changes which are more visible to my manager and release the software with security problems’. In big companies it is very much possible for this to happen. Managers know that even if word gets out that the software was released with known security defects, the resulting inquiry would probably find nothing.

Fifthly, there should be penalty for risk-avoidance. For example, lets say that an employee comes to internal IT department with a request to install the Operating System on their Solid State Device. The IT department refuses to install it saying that it is a risk for them since they do not know how to configure backups properly. The Operating System being installed on the SSD can save developer time which is valuable to the company. But the problem here is that there is no downside for IT department to refuse the request. They have only upsides. Ideally, there should be a penalty for the internal IT in the company so that if the company is spending the money for an SSD, if IT is refusing to make use of it they should get penalized.

Sixthly, people should not be allowed to screw company for short term gain. For example, a new CEO can cut R&D spending for software companies if those projects would only lead to products in a few years. Cutting those projects would mean that the expenses would be reduced ( with no reduction in immediate profits ). Slump in profits comes a few years later when the company has no more new products coming out of the pipeline by which time the executive would have left the company. This problem can probably be solved by paying the executive even after him leaving the company; based on the performance of the team he used to manage.

Seventhly, responsibilities must be handed off properly. Lets say ‘Project A’ uses library built by ‘Project B’. When ‘Project B’ obsoletes a version of the library, ‘Project A’ must be given permission to take over maintenance of the library. Or the manager for ‘Project A’ should force the engineers to move away from ‘Project B’ library before it goes out of support.

Eighthly, you must not use metrics such as ‘number of cases solved’ as a metric for productivity. This is the Coca-Cola bottle mentality. If you do this, you will get the behavior that you incentivize. People will pick up easier cases since they can be solved faster. This is bad since when faced with a problem, it is the skill of your programmers that will decide how well and in how much time it gets solved. This skill is like any other muscle, it gets better the more you use it. It is probably a better idea to encourage your programmers to pick hard problems. ‘Number of cases solved’ in no way represents the amount of work done : the quality of the solution matters, the complexity of the problem matters.

Ninethly, you mustn’t assume that if you put more people into a project it will run into completion faster. Putting more people into a late project makes it later. See ‘Mythical Man Month’.

Tenthly, you must not waste your employee’s time. People who want to live meaningful lives will rue it when their work is wasted. They want to do a good job and when they see their work is duplicated, or wasted because of say, management indecision, they are less amused. This problem is compounded by the recent ‘Agile Movement’, which has taken to mean, the managers can change their mind whenever they want. Project direction, once set, should only be changed if market conditions change.