| Umbrello UML Modeller: A Diagramming Programme for the Unified Modelling Language Developed Using Bazaar Methods; BSc Honuors Dissertation, Final Report; University of Stirling, Department of Computing Science and Mathematics; April 2003 | ||
|---|---|---|
| Prev | Chapter 5. Using The Bazaar Development Process | Next |
I was granted leadership of Umbrello from its original author. He had become leader through the merit that he had written it but Umbrello was now becoming an openly developed programme so, like all major decisions, the leadership had to be broadly agreed by the developers. There is no vote in these decisions but it is obvious that a consensus has been reached and any dissent would be clear. Sourceforge offers different levels of permissions to developers and the formal sign of the Umbrello leader is simply that I have full permissions and can grant permissions to others.
As the leader I do most of the development work but also organise and criticise the work of others. This involves asking for specific contributions and commenting on proposals for features or implementation details. I review all the code which goes into Umbrello either as it is sent to me as patches or once it has been committed to CVS, it almost always requires some tidying up. I also do the day to day maintenance of removing spam from mailing lists, marking bugs as invalid or duplicates and answering user's queries.
It is also the leader's job to occasionally refuse contributions. It can be hard to reject a patch when someone has obviously worked hard on it, fortunately there are few cases when this is necessary and usually a bad patch can be worked on to be improved. In the worse of cases other developers will generally offer an opinion on why the given patch would be a bad idea. Most unsuitable patches are the result of insufficient discussion before implementing the idea, which can be my fault as much as the fault of the person who implemented it.
The position of leader is one of a benevolent dictator, my word is final and any decisions are ultimately made by me. It is benevolent because the freely available and modifiable nature of the source code means anyone can take the code base and start up a rival project if enough bad decisions are made. In reality few such forks have occurred in Free Software programmes, the GNU Emacs and XEmacs split[gnu-emacs-xemacs] probably being the most famous. When forks do occur they can usually be considered branches, one branch used for more adventurous and possibly unstable features, as happened with Samba[samba-tng]. It is the possibility of these forks though which keeps the developers on their toes.
One of my responsibilities as project administrator is to make releases. Although I have never made a release plan listing exact features to be implemented and bugs to be fixed by a certain date I have always had a rough idea of what a release should include. For example 1.1-beta1 was the code that was available when I took over the leadership. 1.1-beta2 included code to read old binary files which was important for not losing long-time users who thought their files were unreadable. 1.1-rc1 was in theory the code which would become 1.1, and the target for 1.1 was a bug free release with the same features as version 1.1-beta1.
Many collaborative projects create a timetable with exact dates for releases and features to be implemented by then. I felt that the development work and number of bugs in Umbrello was too unreliable for this but I did announce a feature freeze as soon as I became Umbrello leader. Due to the number of bugs this was a fairly long feature freeze and, with people so pleased to see development of the programme taking off again, a number of new features did creep in which predictably caused more bugs. It can be difficult to say no to a new feature which is obviously a benefit, but I found a gentle e-mail to the developer concerned indicating the importance of bug free code at this stage in the development would usually cause the bugs to be fixed quickly.
Not all of the GNU/Linux distributions make packages for Umbrello and it is important for us to provide binary packages for as many as possible. From the help requests I get sent it is surprising, for such a technical audience, how many people have trouble compiling a programme. Providing packages is also an easy way to get people involved in the development of the programme.
It is important to encourage and remind users that they can and should contribute back to Umbrello. I always accompany any announcement of a new version with a request for feedback and a statement that any help would be appreciated. Whenever a new feature is added or a bug fixed I make a point of thanking the developer for their help.
I have a policy of offering CVS write access to anyone who has shown that they can contribute to the project. This usually means submitting a patch or two to the developers list. Before I give new developers access to CVS I ask for a brief description of themselves and why they want to work on Umbrello which I put on the website. This is mainly to give some context to a name and helps the developers build familiarity with each other.
Publicity is as important to openly developed programmes as it is to commercial programmes. Without publicity we would have few users and that means fewer developers. Umbrello used to not have a name other than UML Modeller which caused confusion and was too generic for some packagers. I organised a poll on the website offering a number of choices and found a large consensus towards `Umbrello'. The poll and rename was also a signal to users that the programme was going to get moving again.
The website is the most useful publicity tool, it allows users to get an overview and description of the programme before they try it. It includes a page of screenshots showing different functions of Umbrello which offers potential users a quick way to get a feel for what the programme can do. I also added an online version of the Umbrello handbook which contains a detailed description of not just Umbrello but also UML to help convert those who are not accustomed to object modelling.
Umbrello releases are announced on freshmeat[freshmeat-umbrello] and apps.kde.com[kde-apps-umbrello]. The statistics from these sites show that Umbrello has had several thousand downloads through them. I did not send announcements of Umbrello releases to paper based publications but a German developer did and there was an article about it in c't magazine[ct-umbrello-article] so perhaps I should have made more effort to contact English language publications.
KDE is the most popular and (arguably) technically accomplished desktop for Unix. It has made Unix user-friendly enough to be used by any computer user and the large number of applications available for the platform mean users need never know they are using anything other than KDE. KDE is not controlled by any one organisation or company, its direction is solely dictated by its developers. Unlike most bazaar developed projects it has no formal leadership or group of core developers probably because it is such a large project that nobody could manage all of it. Instead each of the applications has its own organisational method and it is considered polite to pay special respect to long standing contributors and those who do a lot of work for KDE (which usually means people who are employed to work on KDE).
The idea of including Umbrello in KDE had been around for some time but it was only after the 1.1 release that Umbrello was mature enough and the release cycles coincided with a recent release of KDE. I suggested the idea on KDE's developers IRC channel to get a feel for what KDE developers would think about including Umbrello. The idea was universally accepted and I followed it up with a more formal proposal to the kde-core-devel mailing list. There was some concern that as the bug tracker was hosted on Sourceforge it would not be a proper part of KDE but I replied that I fully intended to use the KDE bug tracker to ensure that Umbrello was a proper KDE citizen.
KDE developers, like Umbrello developers, need an account on KDE's CVS. Fortunately I already had an account from previous work I had done with KDE. The integration of Umbrello's code base into the kde module kdesdk required some changes to the build files and, because KDE does not allow casting of strings, a few changes to the actual code. I packaged the result, and had it checked over by a KDE developer who had shown interest in helping, before committing it to KDE's CVS repository. With hundreds of KDE developers dependent upon a clean compile of the source it was vital to ensure there would be no problems for any configuration. The speed of IRC came into its own here as several experienced KDE developers and myself fixed possible build issues such as outdated Makefiles, reliance on C functions and the problems with dynamically loadable libraries used for code generators. I moved the items in the Sourceforge bugs and features trackers over to KDE's bug tracker by hand which offered an opportunity to remove some outdated requests and reports. Finally the KDE translation teams were informed of the new programme and I made the current Umbrello translations available for them to add to their KDE translations.
Integration into KDE has already brought us a number of new developers and users. The next release of KDE, which will include Umbrello, will bring UML modelling to thousands of Unix desktops for the first time.
While I stated earlier that Umbrello is not heavily influenced by its more commercial competition, there are a few spin off projects from Umbrello which I have decided not to develop for personally but which I offer support and some publicity from Umbrello.
xmi2code[xmi2code] generates programming code from Umbrello's XMI based file format. Umbrello generates programming code from its own internal objects, a method I prefer for its comparative simplicity, as there is no need to write file parsing code twice and no dependence on file format compatibility.
xmi2html[xmi2html] is a script which uses XSLT to turn Umbrello files into HTML documentation. This is an occasionally requested feature of Umbrello but one which I have avoided because the generated code already includes any documentation in a format specific to that code. Most languages and platforms have tools to convert this to HTML or other formats already, as I have done with Umbrello and kdoc, and this is the preferred method for most developers.
Most significantly there is an Umbrello 2[umbrello2]. It is a completely new programme written from scratch by an Umbrello developer who felt the current code base was difficult to maintain and extend. It is based entirely around MOF and XMI. Currently it does not include a user interface or any code which of more than academic interest. I disagree that a complete rewrite is the best way to improve Umbrello and have found that with refactoring and tidying the code is perfectly maintainable, moreover the current code for Umbrello 2 is almost as large and complex as Umbrello's code without any end user functionally. However if Umbrello 2 does turn into a functioning programme it will encompass much more than UML and be a unique, general and extendible object orientated modelling base.
While it is a shame that the developer time that has gone into these projects has not gone into Umbrello it is important to remember that Free Software is about choice. I would much rather developers who disagreed with some part of the direction of Umbrello's development did so within the project rather than start a completely separate project. By keeping them generally supported by Umbrello, if these offerings do clearly become superior to what Umbrello already offers then they can be easily integrated.
One of the areas of Umbrello which has seen a lot of development, especially from outside contributors, is the code generation feature. I have had code generators sent to me for 11 different languages including C++ and Java, and even JavaScript, XML Schema and SQL. While some of these are obscure for use with object orientated modelling if someone has taken the time and effort to code them it means they must get used.
The reason for the large number of contributions by developers who have often never worked on the programme before is the extendible and clear programming interface for code generators. To create a code generator it is only necessary to understand the CodeGenerator class[codegenerator], no understanding of the internal functioning of Umbrello is required. The API creates an easy way for programmers to contribute to the programme and is particularly suitable for the code generation function because of the large number of programming languages which could be required but which neither I nor the other regular contributors use.
By contrast the code import function, a more complex but similar programming concept, has had no work done on it since it was first introduced with only one language, C++, supported. I have recently been in discussions with developers about creating a defined programming interface for this feature modelled along the code export one. This would allow the success of code export to be shared by enabling developers new to Umbrello to easily extend code import to their own preferred programming languages.
The C++ code import parser is largely taken from KDevelop and effectively represents a fork in their code. It is an example of how Free Software allows for effective code reuse but improvements in the equivalent KDevelop feature have not been ported into Umbrello. Creating a code import API would have the added bonus of allowing Umbrello to link to the KDevelop import library which would prevent two parallel branches of the same code.
What has allowed for the bazaar development model is the removal of artificial restrictions on our use of software brought about by copyrights. Umbrello uses a copying license called the GNU General Purpose License[gnu-gpl] which uses copyright to reverse its normal restrictions and instead allow the copying of the software only on condition that the freedoms to modify and share it are ensured. Copyright has been around for so long that few people consider how, with increases in technology, it now restricts individual freedoms rather than those of commercial publishers. The effect is particularly noticeable in the software industry where copyright has created monopolies that restrict innovation and competition to the detriment of society. Free Software does not prevent commercial software development, Umbrello is sold as part of commercial GNU/Linux distributions and some of its developers contribute to Umbrello as part of their professional work.
Software, both Free and proprietary, is further threatened by software patents, which restrict the very ideas and algorithms used. Software patents are currently illegal in Europe but many thousands are nevertheless granted every year and a proposed EU directive[eu-swpat-directive] will likely soon make them legal. Software patents are something most programmers and educated users object to. Umbrello is probably potentially threatened by dozens of patents, it would be impossible to search for them all, but the Togethersoft patent[software-patents] which restricts round trip code engineering between diagrams and programming code is particularly worrying.
The advent of Digital Restrictions Management technologies now legally protected in the US and due to come into Scots law under a recent EU directive will further threaten what programmers and users can achieve with computers. Trusted Computing schemes such as Microsoft's Palladium will prevent users from running Free Software programmes such as Umbrello on their own computers.