The document discusses the evolution of ad hoc software development into 'ad hoc 2.0,' which leverages web 2.0 technologies to empower end-users and developers to collaborate effectively. This new approach maintains some characteristics of traditional ad hoc methods while addressing scalability and project longevity challenges, allowing smaller projects to compete with commercially developed software. The paper highlights the benefits and risks associated with this methodology, establishing a contextual understanding of its application in modern software engineering.

1. Ad hoc 2.0 – The New Generation
Nuno Brito
CMU/UC Master of Software Engineering 2009/2010
Managing Software Development
nbrito@andrew.cmu.edu
Abstract long time as essential to improve the odds of success
for a professional project in the software industry [4].
Ad hoc software development is the construction of
software solutions through methods and techniques However, with the advent of massive access to the
that are most often developed from scratch during Internet came the emancipation of end-users, providing
project development. Although a reputation of limited the conditions that allowed them to evolve from a
flexibility and scalability haunts this methodology, it is passive state onto active positions inside the project as
nevertheless a powerful technique to build and deploy beta-testers or even becoming active developers that
applications or prototypes within a short period of help to carry forward the progress and lead the project
time. to success. The power of this type of cooperative
Ad hoc will not scale in the traditional format that is development is well described by Eric S. Raymond in
known to software engineers, but web 2.0 platforms “The Cathedral and the Bazaar” [5].
such as forums, blogs and social networks combined
with accessible development frameworks are now The Internet thrives at a web 2.0 era as a global
reviving the ad hoc philosophy as a valid approach to platform that is reachable to a far wider stream of the
developers where this scaling/complexity limitation is population when compared to web 1.0. People from
not an obstacle anymore. Even thought it is not a any gender, age or technical background can
magic bullet that can solve the issues that arise from effectively communicate, work, produce and share
avoiding a more complete and formal methodology, knowledge on a global scale with a relative ease. There
this is nevertheless a growing and attractive trend is an emergent new generation of software projects that
amongst many small sized software projects to produce follow the old ad hoc approach principles but are no
software capable of rivaling side by side commercial longer tied to a restricted group of people involved into
applications from professional developments, resulting development with a high level of knowledge on
in what we define as Ad Hoc 2.0 – The new generation. professional programming activities [2].
On this paper, we will begin by focusing on the way
how ad hoc is currently perceived from a professional
1. Introduction perspective and then perform a more in depth analysis
to attempt understanding the advantages and
Where does the term Ad hoc come from? disadvantages that arise from this methodology when
Ad hoc is a Latin phrase which means "for this contextualized inside a software engineering plan.
[purpose]". It is a common practice to use this term for Later, we approach the concept of Ad hoc 2.0 from a
describing specific solutions applied to a given task or high level perspective that explores the reasons why
problem which cannot be generalized or adapted to it’s use is made possible and attempt to identify
other purposes. common life cycles that projects following this
In the context of software development, an ad hoc methodology might eventually follow. We will then
methodology is often associated to a short life cycle focus on real examples of projects built and maintained
span, or even to the lack of architecture that addresses with some success while employing this methodology
scalability and completeness since the early project to some extent and analyze some of the characteristics
inception. These are characteristics recognized since a that can either lead to success or failure the future of a
project in terms of longevity and large scale software
development.

2. since its inception, but a development process is also
Before we start dwelling onto the definitions between driven from the developer’s talent and effort which
ad hoc in the traditional format and the new format that tends to avoid formalized processes that present
is the topic of this paper, it should be noted that there restrictions to creativity and innovation [13]. When
are some ambiguities regarding the terms: “life cycle”, integrated at an open and global market environment
“methodology” and “process” related to the where innovation and competition are more often than
development of projects. not the aggressive points that help to establish success
[7], can we continue to assume as a correct to regard ad
The author will adopt a consistent and contextualized hoc approaches in such negative manner to the point of
definition of each term throughout the paper in order to software engineers completely discard them as an
ease its overall meaning at each paragraph. To help efficient solution for professional software industry
clarify what each term is usually referred to, some products?
explanation about each term is due: “Process” refers
to the tasks that are executed inside each phase of The criticism mentioned on CMMI about the
development. “Methodology” refers to the set of precarious style of developing software is certainly true
techniques and methods that are employed on these in most of it’s extent, but it is also true that software
processes. “Life cycle” is referring to all phases of the developers still apply ad hoc in their everyday work as
project since it’s early inception until it’s final state of an intuitive and efficient way to manage the resources
release of the product to the customer including available to them. This is an approach that allows a
posterior phases (if any) as help desk support and project in a real world of software competition where
maintenance for example. high levels of creativity under a tight budget of time
and resources become so critical as necessary to
survive.
2. Traditional Ad Hoc development
The most interesting force that drives ad hoc as a
compelling approach is the (in)famous preference for a
2. 1. Concept lack of formal processes since the early inception of
the project. There is a common misconception that ad
Software engineering often tends to consider Ad hoc hoc followers do not follow any formalized process,
with a negative impression when it comes to choose a the truth lies in the fact that an ad hoc project will
life cycle solution against a formal approach. simply be developed without a specific process
methodology followed from a strict and formal manner
SEI (Software Engineering Institute), characterizes since the beginning. Eventually, some formal processes
ad Hoc in “CMMI for development” [10] as a do tend to surface after they are tested and considered
methodology belonging to the lowest possible level: as fit to the custom needs of the project in question but
“At maturity level 1, processes are usually ad hoc and this misconception might lead assumptions that
chaotic. The organization usually does not provide a characterize the overall development as “hackish” or
stable environment to support the processes. Success in even as “chaotic” when viewed from an external
these organizations depends on the competence and perspective that is not aware of how these formal
heroics of the people in the organization and not on the processes are unique to the project in question even if
use of proven processes. In spite of this chaos, maturity they don’t follow a standardized approach.
level 1 organizations often produce products and
services that work; however, they frequently exceed Using nothing more than know-how from the team of
their budgets and do not meet their schedules. Maturity developers mixed with experience acquired during the
level 1 organizations are characterized by a tendency project’s life cycle, an ad hoc project can ensure in
to over commit, abandonment of processes in a time of most cases that whatever processes are adopted along
crisis, and an inability to repeat their successes.” the development cycle, they will eventually be
modified enough to the point of sufficing the needs of
Formal methodologies will often attempt to follow a the project to some extent. The level of efficiency
predefined set of stages intended that provide a certain resulting from these ongoing ad hoc processes is
quality level and management control, in some cases, perhaps questionable as it will depend directly from the
even allow certification of their software practices proficiency and talent of the team elements or even
from a third party entity. These are recognizable derive from user feedback that helps them to be
characteristics for a well engineered product that is elaborated. This is an approach that carries advantages
aimed to reach a higher level of CMMI maturity [10]

3. and disadvantages that will be explored over the next on ad hoc as an approach to allow exploring
section. competitive solutions on the market that allows to
quick releases to public and outperform competitors.
2.2. Advantages and Pitfalls We can identify and detail some of the reasons for this
negative fame:
Ad hoc still holds several advantages as a development • Poor practice of requirements’ elicitation - no
approach since it is well adjusted for projects of predefined set of procedures to properly
relatively small to medium dimension that can be made conduct a requirements elicitation process that
available when time and expected results don't justify allows understanding the scope of a given
the cost of instantiating a formal process. problem. Raising the risk that a given project
can drive a team to waste efforts on solving
For example, ad hoc approaches are very well applied superficial symptoms instead of actually
to cases where a given project requires a proof of solving the reason that causes the problem or
concept before engaging onto a full scale development even mixing requirements with a possible
following a formal approach, or perhaps applied to solution.
projects that are meant for internal use, where
customer, developers and end-users all belong to the • Quality assurance is not measured nor
same company and a formal process is considered to conducted efficiently - without using an
add unnecessary overhead to deliver the product. efficient strategy for early defect detection or
procedures to continuously assess overall
Ad hoc can sustain a high level of motivation and quality through methods such as Fagan
interest from a team since it allows developing a inspections [12], a high density of defects will
project in a light-weight manner that is intended for eventually be discovered after releasing the
release within a short term of time, this is a good initial product version to the customer.
manner to promote innovation and creativity to take
place without too many barriers to development, • Lack of scalability or generality, ad hoc
however, allowing a project to be developed without projects focus their target to a specific
formal methodologies and depending solely on the audience with specific needs. This
experience from developers is also a risk that raises the characteristic will constraint since the initial
odds of impact from several disadvantages that need to days of development the range of evolution
be considered before engaging into this sort of practice. that can be expected in terms of scope, size
and complexity when planning to grow in all
What specific reasons keep companies away from these dimensions. We'll explore this particular
adopting Ad Hoc? characteristic over the next section of this
paper.
Ad hoc inherited a very negative image since the 90’s.
This is the worse factor that still prevents at present its 2.3. Scalability of ad hoc projects
official adoption by professional software developers.
It will also remain as the cause to which people will Scalability is an often desired characteristic on
point their finger when looking for a reason to blame commercial projects that seek a growing number of
for a never-ending appearance of problems that arise end-users as it might bring a proportional growth in
when the inherent limitations to this approach are not revenue. But if the base of end-users grows
properly understood. This approach suffers from the continuously over time, the project will also tend to
same type of issue often associated to companies who inevitably increase in size and complexity. As result,
avoid XP or generic Agile methodologies after passing features will be added, exposed defects will require
through negative experiences due to their initial lack of correction, support for end users and legacy
experience in the agile approach to begin with. This maintenance for older versions will need to be
same factor inducts a catch-22 type of problem where a provided in a scale that will surely continue increasing.
company that publicly admits to use ad hoc on their
projects will suffer to pass onto the outside world an Scalability will therefore impact the development
image where quality and efficiency are not perceived resources that were originally allocated to a given
as reliable, thus causing impact on the reputation, but ongoing project [1]. Ad hoc is rarely prepared to the
underneath the hood, the same company can still rely endurance of time and increase of user base over long

4. terms of time. A project based on ad hoc architecture
will demonstrate it's inadequacy to survive as Open source projects are most often characterized as a
complexity increases, often requiring a complete geographically disperse group of volunteer developers
rebuild from the ground up to match the expected level that enlist themselves to aid at tasks suited for their
of usage and efficiency - perhaps even employing a talent which eventually keep a project moving forward
formal process to achieve the intended results for the on a good level of progress if it retains the attention of
future and no longer be labeled as ad hoc. an audience. The popularity, influence and success of a
given open source project can therefore be directly
These are the most common reasons why companies measured in most cases by the number of users and
choose a formal development process from the start. volunteers that work to ensure it's long term longevity.
Characteristics such as scalability and maintainability
over the long term are planned right from the early The approach for developing these projects when they
project inception and the gain from a quick start and are small sized can be loose and sporadic. But when
delivery as provided by ad hoc will only come with these projects start growing across several dimensions
higher costs to solve as the project itself grows bigger. such as complexity and user base - then a natural
Even thought the bad reputation assigned to ad hoc can tendency to adopt a strict and formal set of
sometimes be considered as exaggerated since people methodologies that allow a team to keep the overall
tend to pick examples where it is certainly not an processes of development under control will eventually
appropriate approach, the truth is that its limitations in begin to surface.
the traditional format are both a blessing and course
that will limit its usage to developers with significant So, we can conclude that regardless of the nature from
experience in the software industry to take advantage a given software product being open source or closed
of most benefits it has to offer without suffering most source, if the dimension of this project belongs to mid
of the recognized pitfalls. or large size and complexity then it will eventually
need to increase the control over the processes for
However, a new generation of ad hoc is surfacing that developing software in the long term if the overall
does not require an extensive experience on software project’s goal is to remain active and popular.
development nor is limited to the same boundaries of
the traditional ad hoc format as before. We will now Traditional Ad hoc usage can be found necessary to
introduce this new concept over the next section. kickstart a project that follows either the open or closed
source type of methodology, we also mentioned
previously that exists a natural evolution of a project to
3. Ad hoc 2.0 – The New Generation somehow expect a progressive formalization of the ad
hoc processes to also occur if enough time is given.
It is a fact that the Internet plays an important role as Or, in more extreme situations, the developers from an
communication platform for people that wouldn't initially ad hoc project can decide to redesign it from
otherwise group together. scratch, using then the formal methods that are more
This access to the Internet world influenced the appropriate to generate a new architecture based on
software development paradigm as reported by Eric S. lessons gathered from past experience on the
Raymond in “The Cathedral and the Bazaar” [5]. development effort. Failing to evolve onto this
However, Eric’s study is mainly focused on the formalized phase of development might eventually
contrasting differences from closed source projects lead a project to stagnation or increase the risk of
compared to open source movements and leaves out becoming overrun by other competing projects.
some of the interesting management techniques that
allowed ad hoc processes to efficiently manage We can therefore infer that a project cannot use
resources in large scale software development projects. traditional ad hoc methodologies as a sustainable
solution for a long term of time and this fact remained
Both open and close source movements share concerns as a solid truth since a long time ago. But when ad hoc
that are similar to some extent about the question of meets the Internet of masses, an exciting new twist on
human managing, quality control and customer the fate of ad hoc projects allows breaking this rule.
satisfaction even thought they are following different
approaches regarding the way how software should be The audience of users interested in joining efforts to
developed. help a given project for absolutely no cost allows
people to organize themselves and develop a project by

5. voluntarily assuming the responsibilities of specific developers can effectively rival against products
roles inside these ad hoc processes. Groups of people developed from commercial companies or provide
will form effective development teams that can per solutions that wouldn’t otherwise be explored by
times outperform professional developers. This can be commercial groups.
due to the high level of motivation and feedback from
multiple perspectives provided by direct contact Ad hoc 2.0 projects have no roadmaps defined for each
between end-users and product developers. People development phase and can often be defined as an
involved in ad hoc 2.0 projects will usually share the ongoing development work whose progress is based on
same domain knowledge in a similar manner to what volunteers and continuous feedback from users.
currently occurs with open source movements.
3.1. Typical life-cycle of an Ad Hoc 2.0 project
There are situations were this type of ad hoc is the
ideal situation for decentralized development without What can be expected from Ad Hoc 2.0?
requiring a high level of control or management. When
efforts are based on cooperative work from volunteers This is a flexible approach. There is no structure that
that are not confined to a strict and formal organization can accurately describe a similar pattern across projects
as noted on many open source movements of bigger of this particular kind, nevertheless, it is possible to
dimension, development will become intuitive and distinguish a few phases that are likely to occur during
dynamic, adapting more easily to the newer trends of the project lifetime.
technology without added costs. This type of specific
volunteer movement can be found across many other The ideal team development condition to allow
projects of small dimension whose code is not forming an Ad hoc 2.0 approach are situations where
necessarily released to the public but where people still only a single developer or a small number of
offer their time and talent to help in tasks such as developers between 2 up to 5 elements are included.
language translation, beta testing, help desk support or There may exist several team elements assigned with
whichever tasks required. secondary roles such as beta testers and such, but the
primary team elements should always be responsible
There is an ongoing trend where the exclusive use of for the most important decisions regarding the project
web 2.0 technologies such as bulletin boards, blogs or progress while sharing the role of end-users on the
any other social networks will allow people across the same project.
globe to communicate and share knowledge between
them. These are the ideal locations where an ad hoc The lifecycle for an Ad hoc 2.0 project will typically
project can progress and reach popularity with the follow 5 distinct phases of development.
increase of users and complexity while withstanding
the test of time without ever requiring the move onto 1. Idea – The concept for a given project is
more formalized practices as seen in the traditional ad proposed by a developer or small group of
hoc format. developers to solve a given problem or
challenge. A brainstorm session between
There is no extensive roadmap, no architecture plan is some of the stakeholders occurs and attempts
detailed, no monitoring of milestones nor extensive to identify possible competitors, alternatives
quality control is conducted, and yet, these are projects and involved complexity to carry forward the
that still manage to provide a product or service that project onto a feasible success.
reaches success and even outperform professional
developments under some situations. This is what we 2. Implementation – The project begins
identify as “Ad hoc 2.0 – the new generation”. implementation shortly after the idea is
accepted as achievable. The project will likely
It's a concept for developing software where some of be coded using a software framework that is
the common disadvantages identified from traditional familiar to the developers.
ad hoc are eventually solved or not even considered
relevant to some extent. There is an important human 3. Initial version – A first version is made
value that is raised from this mass number of users that available to the public as proof of concept that
allows these projects to keep moving forward the innovating idea for the project can be
regardless of their complexity. These projects can be achieved. Usually released to a small group of
based solely on the help and talent from volunteers. It’s people that are close to the development circle
the type of methodology where small groups of in order to gather feedback.

6. development of the project;
4. Revision / Beta versions – Incremental beta 7. Easy to manage– doesn't require team
releases and versions considered as stable are elements to posses a specific formal
published to address bugs or requested education on software development and
features. Very active participation of end- management, a small team is capable of
users in this stage. develop a good product using common
good sense to solve most situations;
5. Stagnation – A project eventually reaches a 8. Lightweight – can be instantiated in a
state of inactivity and either doesn’t fulfill short period of time and keep the
requests from end-users or there is not enough motivation of the involved developers at
interest from the community where it is a very high level of engagement as the
discussed to provide additional feedback. project results are visible very quickly;
Stagnation occurs since the project 9. High number of versions released to the
development is neither announced as public that address new features or
terminated nor the responsible developers will defects fixes;
provide insightful news regarding the project 10. Development driven by user feedback,
progress in the future. progress occurs according to motivation
of authors and user base requests. If a
3.2. Advantages and disadvantages project is popular then it might act as a
good motivator for the author to proceed
Ad hoc 2.0 under this new context remains truthful to with further development;
it's origins – avoid formal processes from the
beginning, change and adapt as necessary in order to And also some disadvantages:
survive. To avoid an extensive list of characteristics,
we narrowed the scope down to 10 advantages and 10 1. It's not prepared to scale or handle
disadvantages that seem relevant to expose on this complexity by default, the effort required
particular development methodology. to adapt onto a bigger user base or code
complexity might be overwhelming for a
Advantages that are commonly found: small development team;
2. No formalized quality assessment as
1. Good for volunteer work as people can there are no repeatable processes to
join at any given time as beta testers or ensure that the project development
even developers in some situations; doesn't cause conflicts with previous
2. Well adjusted to small sized projects as development effort [12];
the level of complexity can still be 3. No metrics defined to evaluate project
completely manageable by a single status makes the task of tracking progress
developers or small team of developers; more difficult to understand by everyone
3. Allows to build strong relationships with involved in the project;
users since they also become an active 4. Risks are often not clearly explored and
part of the development process as beta analyzed before proceeding with project
testers or other roles to which they development, this might force developers
volunteer and help the project effort to deal with unexpected risks that could
move forward; have been avoided from the start;
4. Affordable – requires few resources since 5. No clear milestones with well defined
inception and the development team can goals as the project is governed by the
in most of the cases work on the project specific needs at any given time.
during his free time as a hobby; Defining milestones is a very difficult
5. Localized – solves an immediate need of task unless there is a clear goal to achieve
a specific audience instead of requiring from the beginning;
support for a much wider array of 6. Requirements' elicitation is often
possible users; incomplete as developers tend to opt by
6. Flexible – adjusts well to new delivering a quick fix or patch to solve
requirements that may appear during the symptoms of a problem without
development or to new situations that focusing on the reason that is causing it in
may cause a significant drift on the the first place.

7. 7. No schedule is usually defined in most level of built-in functionality that wouldn’t otherwise
cases as the project progress will depend allow these small sized teams to quickly produce
on the effort and motivation from the applications based on already built user interfaces and
developers, which might lead to many other components that are stable and allow them
prolonged states of stagnation; to focus efforts on innovation.
8. High rate of bugs since new versions are
often released to public without extensive In order for a given project to achieve a competitive
debugging care and often rely on user level and maintain this position, the software processes
feedback to detect defects and prioritize that are employed should also be based on flexibility
their fix. and extensibility rather than high quality as mentioned
9. Defects are not reported with enough by Nogueira in “Surfing the edge of chaos”[11]. The
details because users are not properly goal is to maintain a balance between innovation and
trained for this task, often leading to public interest. Assuming that an ad hoc methodology
ambiguous or incomplete reports about a allows a project to reach the top of it's initial
defect that needs to be corrected. expectations and is well adjusted to keep a large
10. Too many different versions are difficult percentage of users happy with the product for a long
to use and might even paralyze any effort period of time, then there is an important question that
to bring simplicity into a version system needs to be asked: where can software engineering be
that attempts to distinguish between found under this new paradigm?
stable and unstable versions of the
product. We devote the next section to clarify this question and
the implications of processes when viewed from a
Previously, Ad hoc methods would be found applied software engineering perspective.
mostly to software built with the focus on a specific
target audience, the “users by the dozens” [4]. Access 3.3. Surviving to scalability and long-term
to the Internet allowed this specific target audience to development
become amplified from mere dozens to hundreds or
even thousands of users on daily basis. The most desired characteristic in Ad hoc 2.0 projects
is a successful transition to a higher scale of work and
This difference in the scale of masses places Ad hoc in complexity that allows supporting a wide number of
a privileged position as most of the costs from users and developers while increasing the overall
development and research can be reduced to a few quality of services that are made available by the
single developers with talent. Success is often project. Failing to evolve into a more adapted
measured by the amount of people who follow their architecture for the project will eventually lead the
progresses and this is probably the way how software overall development into a situation where the project
development can achieve its most emphatic form: a will no longer be able to keep up with other competing
state of coding where the gap between developer and projects.
end-users of the project is reduced to a bare minimum.
Software Engineering should be employed to explore
This flexibility to release a product often allows more efficient engineering methodologies that are
publishing several minor version updates as prototypes capable of producing processes adapted to a certain
that help developers get a better notion of the ideal type of project and this same engineering practice now
product that answers the ever changing expectations becomes necessary to ensure that this trend of software
from end-users. This type of approach often requires an development can learn how to safely evolve onto a
uncertain number of releases and it’s very difficult to more balanced level of development progress.
perform estimations or assessing the overall project
status but these are also factors that assume a smaller A transition from an ad hoc approach onto a formalized
or less critical relevance in this context. life cycle where processes, architecture and vision for
the project are already defined in advance is not an
The recent software development frameworks are also easy task [14]. In order to understand how this
responsible in part for the existence of this new approach should be executed, it is necessary to look on
generation of developers. Powerful frameworks are in real examples from projects that somehow pioneered
most cases offered at no cost for developers (Eclipse, the path for this thriving Ad hoc 2.0 philosophy,
Visual Studio) as the companies who develop them strongly focused on the power of community work and
have also interest in their mass adoption, and provide a

8. attempt to understand some of the possible outcomes depends on a single developer, Dino Nuhagic, which
for the future, even risking to never actually move onto released the initial version in April 2004. This product
a state where formalized processes can be safely was an immediate success ever since the initial release.
implemented with success. Thought buggy, it would still allow users to save a
considerable amount of time that was previously
required to customize a given Microsoft Windows
4. Case Studies installation source.
The project's development space for discussion was
One of the most seductive advantages of Ad Hoc provided by MSFN (http://msfn.org) – a forum
development is the freedom to create and quickly dedicated to the discussion of windows based
releases to the public a working version of the project technology that was already popular at the time of
that ensures enough innovation and chaos will provide nLite's presentation to public. At that time, this forum
encouragement for volunteers to help and motivate the counted with an average of 342 visitors at each 30
developers into further progress. minutes. Using this site as base for discussing and
presenting incremental versions of the product, nLite
People developing a software product on their free grew onto a user base of thousands over the initial 12
time and publishing it on the Internet will instinctively months, reaching a state of recognized quality when it
be adopting an Ad hoc 2.0 lifestyle without necessarily began being referenced by Microsoft in the official
becoming aware of their selection and inherent knowledge base support channels.
consequences in most cases. It is important to promote
the investigation and elaboration of studies that allow Remaining as a one-man-project, nLite evolved onto
to capture and understand some of the magic behind vLite as the Microsoft Windows Vista Operative
this seemingly chaotic group of processes that seems System was launched. When the family of software
nevertheless be working because of the human factor, products developed by this author began increasing in
exactly as described previously by the CMMI. terms of overall complexity aggravated by a significant
amount of new features added to each recent version,
Therefore, ad hoc is a human instinct approach, a these factors began to toll a visible weight on the
specialized management technique that is applied development effort. The author decided to cease
whenever processes seem to add excessive overhead, development and declared product freeze in early 2008
are unknown to developers or fail to meet a given at the peak of its popularity. Support to the products is
efficiency criteria – as mentioned before, even newer still provided on volunteer basis at the forums but it is
software products can be released using this particular grows increasingly outdated as the products do not
lifecycle as method to bootstrap them and evaluate keep up with the newer released Microsoft Windows 7
their prospective popularity before engaging into a and allows other competitors to compete for filling the
more formal development style. void left by a possible 7lite in the future.
As examples to showcase this style of development, What happened?
three competing software products designed for the
Microsoft Windows platform were chosen. They all Too many arguments can be formulated regarding the
started as products created by stand alone developers reasons why the project came to halt. The author
that later evolved to large scale software systems due himself claimed the need for free time to engage in a
to their expansion by components originated from third professional software development activity. A project
party developers without direct relation to the with increasing complexity and user requests was
development team in some cases. simply too much for a single person to support or one
can also consider that at some given point after so
4.1 nLite many years, the author lost its initial motivation to
pursue development of this project.
nLite is a software product that allows users to
customize or remove specific components from a given What we can infer is that in many aspects, this is still a
Microsoft Windows XP/2003 install CD or Microsoft successful project today, but the fact that it remained as
Windows Vista install DVD. It will also allow to a one-man-project was eventually a weak point that
integrate updates, automate the installation process and allowed development freeze to occur.
integrate third party programs [6]. Its development

9. 4.2 Bart's PE Builder provided on the public forum by volunteers but the
exposed defects and user requested features that remain
BartPE (Bart's Preinstalled Environment) is a unanswered are a serious issue that undermines the
lightweight variant of Microsoft Windows XP or attractiveness for users that now tend to adopt recent
Windows Server Operative System which can be run Microsoft O.S. such as Microsoft Windows Vista and
from a CD or USB drive [8]. It was developed by Bart Microsoft Windows 7.
Lagerweij. The exact date of release for the first
version is not simple to track but it was initially 4.3 WinBuilder
published in the early months of 2003 [9]. The product
was quickly marked with controversy at the time of WinBuilder began as a community spin-off from the
launch. Microsoft was holding the monopoly for a 911cd.net forums into a brand new forum called Boot
solution targeted to Windows system administrators, Land (http://boot-land.net) in mid 2005 [3] by a small
the new Operative System platform designated as group of active users. This software project proposed
Windows PE – which was only available as a to solve some of the issues and feature requests that
commercially product to some organizations. BartPE were not addressed by Bart's PE Builder at the time.
on the other hand, was offered completely for free and The main goal of WinBuilder is similar to BartPE
allowed similar results without requiring a specific regarding the flexible customization of Windows PE
license from MS. boot disks with emphasis in allowing that users can
modify and improve the project, building components
This free solution to the commercial Windows PE from top to bottom according to a given need.
(WinPE) from Microsoft allowed to gather a significant
number of end users, especially after Microsoft have This flexibility allows building extremely tailored boot
no legal basis to contest the legal existence of BartPE, disks projects. With the appearance of subsequent
which attracted considerable attention by the media. Microsoft Windows platforms, WinBuilder became a
This alternative to WinPE was only deemed as legal by software framework for popular projects such as
Microsoft as long as it would respect the Windows LiveXP, VistaPE and Win7PE.
XP/2003 End User License Agreement (EULA).
Flexibility in excess also originated negative
In subsequent years, the product passed through 3 characteristics. Since each WinBuilder project is free
major versions and enjoyed extensive popularity. The to define their own rules and organization, this ad hoc
third and latest version of this product was released in approach causes a considerable lack of stable working
February 2006 [8]. structures for developers to share code and knowledge
across projects. Yet, development remains extremely
BartPE counted with support from the 911 CD Builder active, based on volunteers that keep improving and
forum (http://911cd.net/forums), a forum that was well providing updated versions of this software product
known at the time for hosting other freeware developed and respective projects associated with it.
projects related to the customization of boot disks
based on MS Windows PE and MS DOS. Why is this working?
The success of BartPE eventually eclipsed popularity Decentralized development is clearly present at the
of all other projects hosted at the same forum across heart of this project. Each developer or team of
the years that passed and become the official meeting developers doesn't depend exclusively on other
point for BartPE users around the world. developers and if the development of a given project
enters a freeze state – other volunteers can launch
Unlike nLite, there was no successor of BartPE to the updated or even spin-off versions that eventually
Windows Vista platform and this gap was filled with a provide a good degree of flexibility and progress that
competitor project called VistaPE from Sergey outlives the initial author through other people that
Gurinovich in early 2007. assume these positions in the development process.
What happened? However, development processes have not yet been
formalized nor seems to exist any plan to formalize
The author stopped appearing on the public forums them. Even thought activity remains very visible across
where his project was discussed and avoids replying the several components of the project, new challenges
email messages regarding BartPE, leaving the project are typically solved using an Ad hoc approach.
onto a development freeze state. Support is still

10. 6. Conclusion 7. Acknowledgements
This paper would have not been possible without the
What can we learn from these examples?
support, feedback and help from those across the
Internet that embody this ad hoc 2.0 philosophy on
All three projects shared the same concept of ad hoc
daily basis without expecting more than a genuine
and unplanned development. Supported by Internet
“thank you” for their help to others. I’m grateful to
websites frequented by masses of users from a specific
have had the chance to meet some of these wise
target audience, these projects enjoyed a suited
internauts over the years and even observe from the
platform that helped gather new users and extend the
first row how these developments can truly succeed to
longevity of both the website as the project itself.
survive the test of time, scale and complexity. Would
like to thank in particular to Jacopo Lazzari (Italy),
This model of development is made possible even with
Peter Schlang (Germany), TheHive (USA), Cemal
scarce financial resources. Developers can code these
Tolga Talas (Turkiye) and David Kummerow
products as a hobby during their free time or secondary
(Australia) for their inspiring contribution for this
activity. Even thought the inception of a project first
paper.
occurs with the intent to solve a given challenge, these
products can remain actively used for years to come as
valuable working tools for thousands of users around
the globe in years to follow. 8. References
As seen on the Windows PE case, Microsoft provided 1. Dean F. Sutherland, “A Tale of Three Processes”:
a commercial product to solve a particular market need Reflection on Software Development Process Change
but was eventually driven to rethink their business at Tartan.
model as the freely available alternatives succeeded in 2. Paul S. Adler, Beyond “Hacker Idiocy”: The
gaining the market attention and momentum. Later Socialization Of Software Development.
versions of Windows PE (since 2.x and above) are now 3. Nuno Brito, “WinBuilder”: Case study, 2009.
made available for free for Microsoft Windows system 4. Clay Shirky, “Clay Shirky's Writings about the
administrators. Internet”, March 2004.
5. Eric Steven Raymond, “The Cathedral and the
This sort of community-based development is also Bazaar”, version 3.0, August 2002.
present in open source movements but on the types of 6. Wikipedia
cases in particular of software developments where the “http://en.wikipedia.org/wiki/NLite_and_vLite”, as
source code is rarely made available to others, the seen on 21st of November 2009.
project progress becomes extremely dependent from 7. Paine, Lynn Sharp & Royo, Jose. “Cimetrics
the motivation of the original author unless some Technology” (A1)(9-399-108). Harvard Business
balance can be reached to overcome this dependency. Online (2, February 1999), Paine 99
8. Wikipedia “http://en.wikipedia.org/wiki/BartPE”, as
Software Engineering could have helped the first two seen on 21st of November 2009.
projects presented on this case to survive the test of 9. Bart Lagerweij,
time and continue to extend their popularity. Care “http://www.911cd.net/forums//index.php?showtopic=
about the scalability of the project to newer Windows 837”, as seen on the 21st of November 2009.
platforms or quality assessment techniques might have 10. CMU / SEI - “CMMI for Development” 2006.
helped to simplify the overall software architecture if 11. Nogueira, et al. “Surfing the Edge of Chaos”:
they had been considered since the beginning of Applications to Software Engineering, Naval
development but this was no the case unfortunately. Postgraduate School.
12. Michael Fagan, “A history of software
A single person using Ad hoc to develop a software inspections”: contributions to software engineering,
product with the proper basis in software engineering Springer-Verlag New York, Inc., New York, NY, 2002
processes, awareness of this community power 13. Tom DeMarco & Timothy Lister, “Peopleware”:
provided by web 2.0 technologies, the right amount of Productive projects and teams, Dorset Publishing
motivation that establishes empathy with a target 14. Brooks, "No Silver Bullet”: Essence and Accidents
audience, has all the right ingredients to achieve a very of Software Engineering, Computer, 10-19, Apr. 1987
satisfactory level of success for the future.