During my first weeks with Day I noticed again the importance of effective communication of IT-Systems architecture and behaviour. Day has various complex tools and frameworks and for new employees or project members it often takes some time to understand the structure and behaviour of the systems and how their part fits into the whole thing. This does not mean that Day has bad documentation, but even with direct contact to core developers it is time consuming to understand complex systems and their environment.
Like every complex system software systems are build by joint efforts of many people who need to collaborate with each other. With people joining and leaving projects continuously it is important to describe the systems in a way that others are able to understand them fast and easily and to know how their part fits in. This requires effective methodologies for describing IT-Systems in order to collaborate effectively.
Because visual notations are often easier to read and understand a series of tools have been developed over the years for modeling - and thus communicating - the structure and behaviour of software systems. Examples are UML, BPMN, FMC or YAWL. Often it is possible to use different tools for modeling the same part of a system. You can model the behaviour of a component by using petri nets or UML state charts for example. The challenge is to select the right tool depending on what you want to communicate and who is your audience.
In the next days I will continue this series with some of my experiences and a set of common tips and tricks for modeling that might help you to model and communicate the structure of your software systems efficiently and thus lowering entry barriers for system understanding.
As written in one of my last posts, I took the time during vacation for thinking about some lessons I have learned while building an open source company. In this post I want to give an overview of the facts I have learned. I start with the strategies you can choose as your way of leveraging open source (BTW there are many others, non-open-source strategies, that can lead to success, depending on your market and product) and discuss the benefits that result from the several strategies. Afterwards I explain what you need to consider if you build your business upon open source software.
Open Source Strategies
The first strategy is to leverage the huge amount of open source software available to be more productive (eg. from ASF). I call this the Use OSS strategy. In this case you use OSS software (OK, the name isn't very fancy) as part of your product to speed up development, which in turn can lead to cost savings and better/faster time to market. In detail this means that the usage of OSS frameworks and tools can help you to concentrate on your costumer needs, products and features instead of the many technical challenges you might face like database connections or application workflow.
In case that you want to be a real OSS company and decide to let others participate in your development, you will gain additional benefits like community support for finding and fixing bugs, feedback about useful functions or usability issues. I call this the Be OSS strategy which includes (under normal circumstances) the Use OSS strategy.
Benefits of OSS Strategies
As already mentioned, there are some benefits of OSS strategies that allow you to outsource some of your efforts. But there are additional benefits that might not be obvious. Hiring the right people for your company can be much easier, because there are so many open source developers that work as freelancers and often there is a good chance that you find somebody who is already familiar with many parts of your code (because you use OSS frameworks he already has worked with). In addition you can review the public available sources of an employment candidate which allows you to evaluate the quality of work he is able to provide.
Another benefit of the Be OSS strategy is the opportunity to introduce your product in a global scale, because the possibility for others to participate in the development can lead to many freelancers and small/medium companies that provide local support for users and customers of your products. You can call this the long tail of open source business (according to the famous book "The Long Tail" written by Chris Anderson). But you should be careful with that, because if you are not able to manage partnerships with such local supporters, this can lead to a loss of customer contacts and even if your startup is not able to support customers all over the world, you should know about them. One possibility to handle this problem is to establish a brand name and to license local partners if they want to provide services for your products.
Pitfalls of OSS Strategies
Besides the pretty sounding benefits, there are also some things that need to be considered for a successful open source strategy.
You should use the benefits of fast development and reuse of existing code and frameworks to concentrate on the most important tasks for your product, which means features, quality and usability. One way to evaluate and define those aspects that has proven to work is user-centered design. You can read about our experiences with UCD in Alex weblog. It is always good to provide fixes and patches for open source projects you use, but don't stuck in development of features that are not related to your product.
For that reason it is very important to do a due diligence for open source projects, before you start using them. Some things that need to be considered are:
- Is the projects license compatible with my products license?
- How big is the community of the project and how active is it (eg. date of last mailing list entry)?
- Does anybody else use the project?
- How often do they release and how old is the last release?
- ... (and other questions that might be important for you)
Another important issue is the management of your open source project. Even if many non-commercial open source projects work on an democratic basis, your project needs management to provide reliability for your customers. Thus you should think about development cycles as well as release and build management. Anyway there are a lot of good open source projects, which processes can be used as a basis for your project.
A few weeks ago I was able to install the Mindquarry Desktop Client on a Mobility Office platform that runs on a memory stick. If you don't know Mobility Office, this is a very cool company that provides portable memory devices like memory sticks, mobile phones or iPods with a special software that allows starting applications directly from the device. This means you can not only have you documents and data with you on the road, but also all the applications you need for your daily work.
Below you can find a few pics of the stick itself and a screenshot of Mindquarry running from it. Using the desktop client from that stick allows you to sync your files directly to the stick and take it with you whereever you go.
