The Foggy Risks of Running OwnCloud

IT history is riddled with stories of monumental failure and staggering success.  In the branch of IT that covers the video game industry Atari’s release of E.T. The Extra Terrestrial in 1982 is discussed as a game that nearly destroyed an industry (Snead, 2015).  Netscape’s collapse was considered a death sentence for alternative browsers until its code was open sourced, reworked, and released as FireFox a few years later.  This turnover makes it difficult to determine the true failure of particular projects.  For this paper we’ll be reviewing the collapse of OwnCloud a popular do it yourself infrastructure as a service cloud platform.  The downturn has been recent and sudden garnering enough media attention to describe how various project risks led to its current situation.

In early June of 2016 OwnCloud Inc. closed its doors in Boston after lenders to the project learned the project had forked (Darrow, 2016).  Unlike some forks in the open source community started by a fan with a different vision this fork was started by OwnCloud’s initial developer, Frank Karlitschek who had resigned from OwnCloud just weeks prior.  Fortune’s coverage written by Barb Darrow describes the German based organization as soldiering on through the difficulty (Darrow, 2016) while OwnCloud’s own official blog took a rather firm tone in addressing the fork while assuring customers of continued service (Owncloud, 2016).  The official blog post from the company lists Frank as having “poached” developers to the fork–a strong term in the open source community as developers are often volunteers who choose to contribute their time and talent to someone else’s ideas.  

The funding shortfalls and thinning of community developers has left a significant scar on OwnCloud’s ability to develop on its projected pace.  It may also be putting the company in jeopardy as Frank’s fork, NextCloud has not only gone live, but garnered considerable press attention (NextCloud, 2016) in the process.  This developer exit and fork are likely the death sentence for OwnCloud.  While funding and developers are explicit risks identified by OwnCloud in their press statement, media attention/momentum and schedule are implicit risks that affect the project going forward.  In this paper I will describe each of these four risks, as their impact and the company’s response/potential response using the Project Risk Identification Framework illustrated in our text (Marchewka, 2015).


Resource constraints exist in all projects and presents a risk towards project completion.  Early on in the creation of OwnCloud there was a need to raise revenue in order to hire the staff that would be able to move the project forward.  To solve this problem, OwnCloud created a business model that would license certain features of the platform.  This payment model would allow the business to continue to develop the software.  

Working with the Project Risk Identification Framework we see that the Measurable Organizational Value (MOV) would increase if the project were successful.  A budget was required to be able to achieve the project’s scope and quality goals.  This required people to be able to create the product.  Since all of this was within the same organization the risk was internal and known.  Since the risk was identified early on the team developed a project charter and plan.

The initial impact of this decision was immediate.  Funds began coming in enough to hire employees and coordinate other resources that gave the project a legitimate status among its competitors.  The longer term impact was that the implementation of the licensing program alienated large parts of the community over time.  The organization behind OwnCloud became beholden to those who were paying the bills at the loss of those who were contributing code to take the project in new directions.  As a result the project forked in June of 2016 with several core developers moving to build the forked version’s functionality under the title of NextCloud.

The company’s response to the risk has always been to cater to the hand that feeds it.  This is not to say they haven’t tossed a bone or two in the direction of the community contributors, but the company devalued input on proposed features from the community (Fisher, 2016).  After Frank and other key developers had already left OwnCloud the company they did announce a community board stating,  “One of Frank’s criticisms concerned the need to strengthen the Community. In this regard, we have been working on the creation of the ownCloud Foundation, the formation of which we announced earlier this week” (OwnCloud, 2016).  This effort was seen as too little and too late.  

If the company had formally adopted a risk management plan they might have been able to more fully calculate the risk of losing the software’s founder and several key developers.  Since the key person to leave was the original author of the code it might have been taken for granted that his contributions would remain constant.  If a risk matrix was developed early on this would have been a sure assumption, but as time went on updating the risk matrix to adjust for shifting attitudes within the work environment would have been key.  Unless key decisions were made to find other budgetary models early on I believe that the results would have been inevitable.  This is like 1990’s Kodak having the patent on the digital camera and not being able to do anything with it because it would mean destroying their film business (Pachal, 2012).  


The second explicit risk identified by OwnCloud is that of their developers.  While we have already discussed how the developers were impacted as a result of budgeting decisions, we need to look at how the developers are a risk to the project.

Developers add value to the MOV by creating the code that fulfills the project’s scope and quality goals.  They are a cost to the budget and more developers properly organized are required to get the project to stay on schedule for its paying customers and loyal fans.  There are two categories of developers contributing to OwnCloud, paid and volunteer.  

The paid contributors are few but have a large impact on the budget.  The volunteer contributors are much larger and indirectly reduce some of the budgeting items by contributing code that would otherwise need to be paid for from a hired developer.  Open source community developers have a reputation for being security conscious and are known for finding security flaws in code and applying patches quickly.  From this standpoint the OwnCloud community saved the company a considerable sum auditing nightly code for vulnerabilities.  Their disorganized nature often results on costs from an organization standpoint.  Sometimes it’s hard to herd cats.  Eric S. Raymond talked about this in his book, The Cathedral and The Bazaar.  He argues that the chaotic nature of organizing open source contributors may be difficult, but if managed properly can lead to tremendous results.

The risk of losing these developers directly impacts the organization’s ability to deliver and improve its MOV.  Because there are two categories of developers the risk is both internal and external.  These risks were known unknowns.  Thanks to the abolishment of slavery individuals have the right to choose their employment.  Paid and volunteer employees can choose to exercise their talents for other organizations beyond their current affiliation.  Since these issues were known unknowns but weren’t captured on an updated risk plan the company failed to act until after the results were realized.  Their announcement of the split appears to be evidence of an organization in the executing and controlling phase, but with less resources to execute and control.

The risk response has been to hire a new CEO, Tobias Gerlinger who as noted in the blog post announcing his ascension to CEO, has spent a great deal of time securing funds for the organization (Dyroff, 2016).  This clearly addresses the issue with budgeting, but does not necessarily create a focus that encourages community programmers to return to the effort.  It’s very likely that more paid developers will appear on staff soon with reduced emphasis on community developers.


One implicit risk associated with any business or project is media attention.  Media attention works to improve the organization’s MOV by reducing the budget required for advertising a particular project.  This free advertising can in turn affect the process for releasing information.  Good press encourages more press releases changing the internal processes to keep up with demand.  While this may affect internal processes.  Media attention is primarily external.  OwnCloud certainly had a compelling story to tell of a small OpenSource project operating in a tough market against giants like Google with their drive solutions, MS Sharepoint, and DropBox (Darrow, 2016).  Media attention is a known unknown.  It’s certainly something that’s anticipated, but can’t be fully calculated.  Some press builds upon itself while other releases never reach that critical mass.  In response to a lot of OwnCloud’s positive press throughout the years the organization has really been able to evaluate project success as the press has provided feedback for iterative successes in each release.  In addition they’ve been able to adapt this feedback towards the next release and incorporate recommendations that become part of the next project plan.

Media attention with any software system is important as it can translate to free advertisement and increase customer awareness and broaden customer base.  With OpenSource it’s crucial.  OpenSource developers are often motivated by the credibility they gain from contributing to projects.  The more high profile projects they contribute to the more credibility they gain.  The more high profile the project is the better target it is for attracting developers looking to get an ego boost (Raymond, 2003).  

Positive attention can make a significant contribution in attracting developers to further the work.  The response to the negative attention was equally detrimental.  In some cases the coverage focussed on OwnCloud’s press release but in many cases the coverage focussed more on Frank’s new fork.  While not overly critical of his former company he was critical of parts that allowed him to garner the sympathy of several who interviewed him (Lunduke, 2016).

Since the press is so influential in open source development I believe it is important to have a full time press agent as part of the paid staff of any project.  Having a trained professional who can clearly communicate and improve community perception when things go wrong can only serve to assist the organization.


The final implicit task I would like to discuss is that of the project’s schedule.  With fewer developers, bad press, and a restricted budget OwnCloud may be as near to failure now as it ever will, but failure doesn’t always mean the organization is closing shop.  Often in open source development failure means a reduction in output over time and reduced adoption as feature sets become more dated.  A good example of this is Apache’s OpenOffice vs LibreOffice (Hoffman, 2015).  

Schedule directly affects the organization’s MOV as the pace of development often impacts the quality of the output and improved feature sets can often attract more customers.  The risk to schedule is one that affects both product and technology.  Schedule is primarily internally driven although it may depend on external factors.  Schedules are generally known-knowns as they are built on calendars with accurate work times associated with them.  There is risk involved in not properly estimating the duration of time for a particular effort to be completed, but this can be reduced through similar iterative tasks and organizational experience.  For OwnCloud it’s issues occurred just as they were about to release version 9.0.3 and version 8.2.6 both of which seemed to be unaffected by the larger issues with developers (OwnCloud, 2016).  The pace moving forward is expected to be much slower.  Its earlier projected pace was determined when a certain quantity of developers were available and now the organization finds itself with a deficit of developers.  Instead of directly wooing those who might contribute the new CEO has announced increased funding resources to be able to continue to maintain contractual obligations with existing customers.  NextCloud will likely overshadow OwnCloud with features over the next few iterations.

While the CEO’s response was to be able to secure the company’s financial viability moving forward I would have recommended that he immediately hire individuals capable of managing the community and work to rebuild relationships with volunteer developers.

In part 2 of this paper I intend to discuss three other risks, their potential triggers, rankings and recommended responses.  The three risks I have selected are project scope, quality, and organization.  The failure of OwnCloud to maintain its founder and other key developers is a serious blow to the organization and its ability to move towards a higher quality product.  While we’ve already discussed various risks and their impact in this section we’ll look specifically for risk triggers and rankings for the associated risk with a recommended response.


The first risk to discuss in this section is the risk to the project scope.  Much of the conversation that lead to Frank leaving OwnCloud.  Although cautious about going into detail in his initial post, Frank explains his reasons for exiting thusly:

I thought a lot about this situation. Without sharing too much, there are some moral questions popping up for me. Who owns the community? Who owns ownCloud itself? And what matters more, short term money or long term responsibility and growth? Is ownCloud just another company or do we also have to answer to the hundreds of volunteers who contribute and make it what it is today?

These questions brought me to the very tough decisions: I have decided to leave my own company today. Yes, I handed in my resignation and will no longer work for ownCloud, Inc. (Karlitschek, 2016)

The moral questions Frank expresses here are really questions of scope not only with the code, but with the organization he helped to found that underwrites that code.  He identifies the risk trigger as being the culmination of uncomfortable answers to these important questions.

From the perspective of OwnCloud the risk trigger would have appeared much earlier.  It’s very likely that Frank asked these questions of his coworkers, but was unable to find suitable answers.  The asking of those questions should have been seen as a risk trigger since they indicate a different attitude toward the project scope than what was being implemented by the organization.  

When a person frames an argument in moral terms there is no higher level of argument for them to present.  From Frank’s perspective the moral scope of the project was paramount.  From OwnCloud’s perspective this risk was also highest among the three discussed in this section as it contained the highest potential for negative consequences moving forward.  We do not have a clear time scale illustrating precisely when the scope risk become an issue or when the triggers were ignored over the project’s lifespan, but we do know that triggers were ignored between its initiation and its current status.

The proper response should have been to review the project’s documentation for information about change management.  The business’ scope for the project had evolved from what Frank’s initial scope was (Lunduke, 2016) to the point where his presence was untenable.  


The second risk I would like to discuss in this section is that of quality.  Quality refers to matching customer expectations with the product itself.  Although specific feature sets being adopted or rejected is certainly a question of project scope, the ability of those feature sets to meet customer expectations is certainly a question of quality.  OwnCloud’s responsibility to quality includes code capable of performing in accordance with its defined feature set.  This includes a large amount of effort applied to hardening the code.  In addition to code fortification, quality also includes giving priority to certain users.  This preferential treatment of features for paid customers disagreed with the philosophy of quite a few in the community.  In short they believed they were shipping a product to the community that was inferior to the potential the project could achieve for its customers.

Despite Forbes’ article highlighting that the cloud storage market has serious competitors (source), the self hosted cloud storage market has only a few.  So while OwnCloud might be competing with big names for average users to the user base that categorically rejects the big names, they were effectively the only game in town.   The risk of not having quality software meant losing a critical mass of marketshare to its competitors or losing the critical mass of marketshare to the community that the organization was based upon.  The critical mass of users and volunteer developers is key in open source projects.  Losing them would mean losing the momentum of the effort.

This risk is second in priority to that of scope.  While quality does affect the number of users and contributors, it doesn’t affect the idea behind the code itself, simply its implementation.  The disagreement that lead to developer exit manifested itself in quality (different code for different payment models) but it was in large part a question of scope.

My recommended response for this situation would be in line with what NextCloud is currently doing.  They are re releasing the software without the restrictive CLA agreements of OwnClouds’ customers.  They’re truly open sourcing the entire stack of code.  While OwnCloud was unable to find a business model that supports such a move, NextCloud appears to be focusing heavily on community contributions to the code first and the business model second.  If you’re going to have community input on a project then you’re going to have to respond to the risk of losing the community early and often.


The final risk worth mentioning in part two is that of change management.  This risk occurs when a project fails to adopt a plan to manage changes that will occur throughout the project’s lifecycle.  In some software development models change management is more prevalent than in others.  An agile software development method allows for small incremental changes over time that lead to a user focussed deliverable that generally meets expectations.  The Systems Development Life Cycle (SDLC) method is generally more difficult to inject change during the process than agile.

As mentioned earlier the conversation about what is and isn’t OwnCloud’s software and who does and doesn’t own it is really a question of scope.  As OwnCloud moved from an individual project to a fully licensed company the goals began to diverge.  The feature set for each incremental release adopted fewer of the ideas of the community over time.  When meetings took place to determine the correct feature set community members were given more and more limited voice.  In this regards it’s not just that OwnCloud didn’t have a good change management plan, it’s that they became complacent in adopting the feedback from the one they did have.

The severity of this risk has certainly contributed to the developer exit, but I would rate it as the third highest risk because it wasn’t as likely to occur.  Unlike closed source software models OwnCloud clearly had community input.  This meant that there existed a change management plan.  These two things on the surface make it appear unlikely that this risk would have increased in probability, but through ignoring the community that’s precisely what happened.  In the process several risk triggers (frustrated contributors voicing concern) were ignored over time.

My recommended response for this risk is similar to that of the other two discussed in part two.  Cater to the community!  Addressing this specific risk is less about communication strategy and more about adopting community ideas and publicly complementing the effort.  By ignoring the community you communicate that you devalue their input.  Supporting their ideas and incorporating their potential into your change management strategy would show the opposite.

In conclusion ignoring the risks that OwnCloud faced from inception to fork directly contributed to the project’s developer exodus.  Several key triggers were missed during the project’s lifecycle including key contributors asking deeply moral questions about the scope.  This research has further exposed to me the potential weakness of open source projects in partnering with community developers.  Such partnership appears to be extremely valuable but adds the risk of losing their input if key points they rely upon are ignored.


Darrow, B. (2016, June 02). Why Did File Sharing Startup OwnCloud Shut Down? Retrieved July 17, 2016, from

Dyroff, H. (2016, July 14). OwnCloud. Retrieved July 17, 2016, from

Fisher, C. (2016, June 5). Jumping to the Nextcloud | Linux Action Show 420. Retrieved July 17, 2016, from

Hoffman, C. (2015, August 28). Why you should ditch OpenOffice and use the free LibreOffice suite. Retrieved July 17, 2016, from

Karlitschek, F. (2016, April 27). Frank Karlitschek_. Retrieved July 17, 2016, from

Lunduke, B. (2016, June 02). Live Q&A: OwnCloud contributors create Nextcloud. Retrieved July 17, 2016, from

Marchewka, J. T. (2015). Information Technology Project Management, 5th Edition. John Wiley & Sons. (2016, June 2). Nextcloud. Retrieved July 17, 2016, from

OwnCloud GmbH. (2016, June 2). OwnCloud. Retrieved July 17, 2016, from

OwnCloud GmbH. (2016, July 1). OwnCloud. Retrieved July 17, 2016, from

Pachal, P. (2012, January 20). How Kodak Squandered Every Single Digital Opportunity It Had. Retrieved July 17, 2016, from

Raymond, S. (2003). The Art of Unix Programming. Retrieved April 04, 2016, from

Snead, J. (Director). (2015). Video Games: The Movie [Motion picture on DVD]. United States: ANCHOR BAY.