Welcome to the SharpE Case Study Project. This is a companion page to the SharpE White Paper Experiment.

This case study is being done in conjunction with/for CodeGear, who make Delphi. This is a spot for brainstorming and getting the ideas out there, fnding answers to questions we never imagined asking ourselves (or being asked), and possibly discovering a new thing about or to do with SharpE.

This document will follow the actual outline of the case study questionnaire sent to me by CodeGear, and there will be a section at the bottom for comments and questions and ideas.

1. Tell me about the application you are building (have built)


1. What industries/customers/users does your application serve?

  • SharpEnvironment? is targeted at end users who are running Windows 2000 through Vista.

2. What is a typical user profile for your application?

  • Generally a user of SharpE is aware of what a desktop environment/shell replacement is, and is familiar enough with his/her machine to be unafraid of changes to their UI. Many users have used other shells in the past and we have seen a surge in the number of users who have defected from another shell which is no longer in active development, or which does not allow the level of customization SharpEnvironment? offers.

3. What business functions/activities are enabled?

4. What is the business problem being solved by the application?

5. Type of Application – desktop, client/server, multi-tier, Internet/Web

  • This is a desktop application in general. Some features such as the weather service are updated over the internet.

6. Characterize the type of your company – consulting firm, large enterprise, small business, individual, etc

  • We are a small Open Source development team composed of students and hobbyists. At least one of our team members has used Delphi in his profession.

8. List a few of your representative users

  • Our users include eye candy enthusiasts, users who have come from using another shell, and a number of people use our shell because they like the configurability and added fuction to windows that is similar to Linux, but don't want to change their OS.




2. What were the development objectives and challenges?


1. Objectives – e.g. (requirements?)


1. time-to-market

  • There is no specific time to market, due to the shell being Open Source. The development schedule is largely regular due to scheduled testing days which lead up to a new release.

2. market or technical leadership

  • Configuration should be provided visually abstract, and not by editing multiple XML files. They should also appear in a modern and consistent way.
  • The shell should be visually appealing to the user, "Eyecandy" should be an important factor.
  • Interface and how the shell works should be consistent through the usage of different skins and themes, the user should always be able to find the same functionality even if the shell looks completely different by using other skins. (Using a different skin or theme should not change how the shell is working).

3. transition to new tools, databases or platforms

  • Using Graphics32 library to handle most drawing and rendering functionality.
  • Usage of XML for handling all settings. (Using the windows registry for saving settings is too limited)

4. If internal – a business opportunity. If external business – a competitive threat?

5. Replace legacy or old application/infrastructure

  • Replace the explorer shell/desktop with a modern, very functional and easy to customize interface

6. Modern architecture

  • Development should be modular, so that functionality roles could be easily distributed across members.
  • Graphics should be completely designed and used as modern transparent graphics supporting full alpha blending for skins, icons and all other graphics. (full support of png graphics)


2. Challenges – e.g.

1. software archeology

  • developing a modularised application, and only supporting Delphi plugins (not supporting 3rd party languages such as C++). This was by choice.
  • developing an application which has to emulate certain functions of windows which are only barely documented by Microsoft (i.e. System Tray).
  • chosing a licence under which to release the source code online. Reading and understanding all the different available source code licenses can be a nightmare if you aren't experienced with such things.

2. outsourced or distributed dev team

  • lacking project management skills, although this is now much improved, early on development this was a major issue
  • development team distributed across the world (time zone differences when trying to communicate and work together)
  • sometimes developers only barely reachable via instant messanger (writing an e-mail every few days isn't enough to effectively develop a big product)
  • it can sometimes be very hard to motivate yourself to spend that much time working on a project if you are only working on it alone from your home PC (it's very different to when it would be your job to work on the project). That's why communication between the developers and feedback from the community is very important. That provides the necessary motivation to continue working on the project.
  • most developers have never received professional training so the actual coding style and the knowledge of certain things can be very different between the developers. It can happen that one developer has never heard of things which seem perfectly normal for another developer. This sometimes can cause come confusion when working with code someone else wrote.

5. Team size constraints

  • developing a huge project, while trying to juggle studying or a full time job
  • finding new developers who are experienced enough and willing to really help on the development. An open source project attracts many developers who are interested and eager to help at first, but most are losing interest or seem to give up when they realize how much work is involved in such a big project. This often results in semi active developers joining the development who then never or only with very slow progress finish their given tasks (this slows down the whole development process).

6. Budget constraints

  • only possible to use free and open source software due to the fact that the project is open source itself and no money is earned with it. This leads to the problem that the development has to rely on free available versions of the development evironment which was and still is the biggest problem in the development of the project because after Delphi 7 Personal the support from Borland for free personal editions has nearly stopped (Delphi 2005 Personal was only included on a few cover CDs of PC Magazines). This has now improved with the release of Turbo Delphi, but still the restriction to not be able to install any third party component into Turbo and not having a command line compiler included are still the biggest problems. The community for third party components is very strong in Delphi, it's the biggest reason which keeps Delphi alive for non professional developers and the reason why many people are still using Delphi 6 or 7 as their development environment (because it's not possible to use them in the personal editions of any modern delphi version).


3. Benefits

  • I feel I should address this b ut i'm not sure how(spj)

1. Increased advertising opportunities and revenue

2. Created larger viewing audience, new customers

3. Conserved resources by keeping team small

4. Strengthened brands and bolstered product loyalty





3. Project management information / Product selection information


1. How would you characterize your business – ISV, In-house dev team, VAR?

  • Open Source development team. We are small but all development is done by us and our community. Each staff member is a volunteer and when outside help is needed, it is found within our community of users.

2. How long have you been using CodeGear? products in this project?

SharpE has been written in Delphi since its inception on 10 March, 1997.

3. What were your criteria for tools selection?

  • Open ource or freeware
  • Possibility to customize the tools to our needs (Trac, CIA SVN Stats, ... see 3.7)

5. How many developers are on the team? How are they organized?

  • three core developers (coders), one lead designer, one community/PR manager, several experienced testers (who are considered part of the development team)
  • not officially on the team but worth mentioning are several third party developers who are using the source code to write plugins to the application and to submit smaller patches to the source code (new plugins and patches to the source code svn are reviewed by a core developer before beeing implemented)
  • organized through constant instant messanger, e-mail and IRC contact and the usage of a bug and feature tracking system (trac,... see 3.7.)
  • every developer has his own part of the shell on which working he is most experiences on (mostly because he wrote that component/module). Fixing bugs and implementing smaller new features is done by all developers through the whole shell.

6. Which CodeGear? products did you use?

  • none for project management

7. Which non-CodeGear? products are also in the mix?




4. Technical information about the application


6. What third party components were used (e.g., TMS for ribbon menus)? Why?

  • JEDI Code Library (JCL) - http://sourceforge.net/projects/jcl/ - used to gain easy to use functions for retreiving system informations and to use some advanced and easy to use functions for String manipulation and directory/file management
  • JEDI VCL For Delphi (JVCL) - http://sourceforge.net/projects/jvcl/ - primary use is the TJvSimpleXML component which is used to handle the XML settings. Several configuration dialogs are also using other visual JVCL components.
  • Graphics32 - http://www.graphics32.org - Highly advanced and powerfull graphics library used for the skin system, desktop and nearly all graphical effects.
  • PNGComponents - http://www.thany.org/article/32/PngComponents - used for the PngImageList? component mostly, which allows us to include png images with alpha blending in our projects.

7. Were there legacy applications and/or compatibility issues to address?

  • Originally Windows 95 and 98 were supported. This was dropped in favor of the newer, and more stable, NT based operating systems. Main reasoning for this was that in order to support the newer Windows versions, many things were broken in older Windows. Eventually it was decided that rather than essentially having two code bases, that support for the older versions could be dropped. An influence on this decision was Microsoft themselves dropping support for Windows 9x.

8. What platforms are you developing on/for? Why are these important? …

  • Windows 2000, XP, and Vista are supported. These are the most common operating systems in use, and as such we feel they are important to develop for. While Windows 2000 is older, due to it also being based on the NT kernel, supporting it is usually a trivial task.

9. What is the development history of the application?

  • project founded in 1997.
  • between 1997 and 2004 very variable project activity. The project had more developers but also many developers coming and going. At some points the development progress slowed down very much due to the project being not organized well enough. Development progress and organization have improved a lot since then.
  • since beginning of 2005 the current development team is doing a complete rewrite of all parts of the application (supposed to be finished by 2007)

10. What are key architectural elements of the new application? How is each important to enabling the business purpose of the application?

  • modular design... The application consists of a few core applications while the whole content of those applications is distributed as dynamic link libraries which are loaded as modules/plugins into the core applications. Core applications are also written to perform specific tasks, rather than having one large application. An advantage here is that bug fixes and updates can be more easily distributed.




5. CodeGear? products used


1. Which CodeGear? products were used? Which versions? For development, for deployment?

  • Borland Delphi 6 Personal Edition (1997 - 2006)
  • Borland Delphi 2005 Personal Edition (2006 - 2007)
  • CodeGear Delphi for Win32 (2007 - ...)

2. Key features utilized and specific benefits you received from their use?

  • The main reason for using Delphi is the programing language and not the development environment.
  • The clean and easy to use Pascal syntax helps a lot to easily understand source code written by other developers
  • Pascal is both powerful enough to perform the tasks we require of it, and easy enough to use that it is easy for new developers to learn. Because of this, we can make it easy for third parties to develop modules and plugins for our products.
  • Delphi has a very strong community for free and open source third party components which can make things a lot easier.




6. Results


1. What feedback have you received from developers? Users?

  • Many of our users have complimented both the appearance of the software, and the support that we strive to offer.

4. If this is a product for sale – how many customers purchased it? Revenue level? …

  • The product is distributed as free software. Including third party websites the last official release has about 100.000 downloads in 2 years.

5. Selected quotes from successful users?

  • "Oh wow... What can I say guys? I've been playing around with Sharp E ever since CVS6 was considered "new", and as impressed as I have been then, that's nothing compared to how impressed I am right now... Sure, it's got some bugs and niggles, but TD3R2 is stable enough for my everyday use, and that's a small price to pay for this level of shell customization...

Get it stable enough for consumption by people who won't panic at the slightest bugs, and I'll make sure at least my closest friends are converted...

And strangely enough, at least to me, Sharp E is probably one of the most active, most fully featured freeware shell replacements in development nowadays... Not bad for a shell rep that was once considered only for newbs (NOT MY OPINION, I read it in a shell forum somewhere) ...

Keep up the good work guys, and DO buzz me for the next TD... I'd love to do what I can to aid the development of my current favourite shell rep!" - user eiraku

  • "the latest testing day version looks hawt. you guys are making some great stuff here" -user nny77




7. What’s next

1. Software is never “done.” What can you share of your functionality roadmap?

  • Unicode and Multi-language support (0.9)
  • Online update, internet based and via a client service (0.9)
  • Tablet Support, which would make us the only Windows environment to offer tablet support.
  • Widgets service




8. Team Profiles


Name: Martin Krämer
Team Role: Project Lead and Lead Developer
Joined: 2004
Age: 23
Location: Germany
Occupation: Studying at the Friedrich Schiller University Jena (Germany) for a diploma in physics (5th studying semester at the moment)
Programming Experience: 10 years Pascal, 8 years Delphi, 2 years C++ and 1 semester Java
Programming History: No professional training at all, mostly everything self taught and learned by working together with other developers online

Name: Lee Green
Team Role: Project Lead and Lead Developer
Joined: 1999
Age: 28
Location: UK
Occupation: Full time Delphi/C# Software Engineer at a HR firm (Link HR)
Programming Experience: 14 years Pascal, 10 years Delphi, 1 year C#
Programming History: Educated to degree level in Computing and Management Sciences, 6 years professional Delphi experience. Delphi was self taught, and still learning collaboratively with other developers each year.

Name: Nathan LaFreniere
Team Role: Project Lead, Lead Developer, Server Admin
Joined: 2006
Age: 23
Location: USA
Occupation: Direct Support Staff for the Developmentally Disabled
Programming Experience: 11 years Visual Basic, 9 years ASM (Using Windows API heavily), 4 years C/C++, 3 years Delphi, 1 year C#
Programming History: All languages were self taught by reading online tutorials, and working with other developers.

Name: Collette Bender
Team Role: Project Lead, Manager of Community Development and Public Relations
Joined: 2005
Age: 32
Location: USA
Occupation: CEO of startup company
Over 10 years experience in community building, market and consumer research, and promotion.