The Forge and the Bargain: How VA Software Turned Open-Source Workflow into a Control Surface—and Then Sold the Pieces

Summary

• VA Software controlled more than a code host. SourceForge.net combined project identity, discovery, repositories, issue tracking, mailing lists, releases, download statistics and an influential technical audience, giving its operator unusually broad power over how open-source work was found and coordinated.
• The company converted lessons and credibility from that public service into SourceForge Enterprise Edition, a separate proprietary product for organisations that wanted development activity behind the firewall, connected to corporate identity, reporting and existing source-control tools.
• The two sides had different economics. The hosted community produced attention that could be sold to advertisers, while enterprise revenue depended on long sales cycles, installation, integration, maintenance and support. Filed results show rising software revenue but continuing software operating losses before the business was sold.
• The 2007 sale drew the decisive boundary: CollabNet acquired the enterprise product, intellectual property and much of its working team, while SourceForge.net and the media audience stayed with the company that renamed itself SourceForge, Inc. Customers and maintainers therefore inherited different successors.
• The durable lesson is a governance one. A free collaboration service can become critical infrastructure before its users have tested portability, change-of-control protections or the operator’s incentives; an on-premises product can reduce hosting dependence while creating a different dependence on proprietary workflow, integrations and support.

One word, two control surfaces

On 24 April 2007, “SourceForge” stopped being a useful answer to the question of what VA Software owned. The company announced that CollabNet would acquire its SourceForge Enterprise Edition business, including the relevant intellectual property and assets, and would offer jobs to members of its development, support, sales and field-services teams. Yet the transaction expressly left SourceForge.net—the public project-hosting service—with VA Software. A contemporary account described the exclusion plainly: the public site was not powered by the enterprise product being sold. A single brand had concealed two systems, two groups of users and two different sources of power. The sale made the seam visible. The company’s SEC-filed announcement and contemporaneous reporting on the exclusion establish that distinction.

That seam is also the key to identifying VA Software itself. This was not simply a loose label for every business that later used SourceForge, nor was it the current operator of the SourceForge website. The corporation began as VA Research and became known for Linux hardware. In 2001, after leaving the hardware business, its board asked shareholders to approve the name VA Software Corporation. The reason given in the company’s proxy statement was unusually direct: developing, marketing, selling and supporting SourceForge collaborative software had become its primary business, while “VA Linux Systems” still suggested hardware. Shareholders approved the change in December 2001. The identity examined here is therefore historically bounded: VA Software after that transition, and before the May 2007 change to SourceForge, Inc.

The boundaries matter because the assets travelled in different directions. The enterprise product and its customer obligations went to CollabNet. The public site, the advertising audience around technical media properties and the ThinkGeek commerce operation remained with the original corporation. That corporation then adopted the SourceForge name and, in 2009, became Geeknet. The public site itself was sold again in later years.

Treating all those periods as one continuous company would attribute decisions to the wrong owner; treating SourceForge.net and SourceForge Enterprise Edition as the same software would misunderstand what buyers bought.

Within the bounded VA Software period, however, the two surfaces were strategically connected. SourceForge.net was the public workshop: a hosted place where maintainers could organise projects and users could discover and download them. SourceForge Enterprise Edition was the private control room: software sold to companies and public bodies that wanted comparable coordination inside their own security perimeter. The public site supplied proof that a browser-based collaboration hub could work at substantial scale. It also supplied a famous name and contact with developer practice.

The enterprise system turned those observations into paid governance—permissions, reporting, integrations, support and a centrally administered record of work.

This was a clever bargain, but not a stable one. Public maintainers valued autonomy, free access and the ability to inspect or reproduce their tools. Enterprise buyers paid precisely because a vendor could standardise those tools, constrain access and accept a support obligation. Media economics rewarded audience growth and page views; enterprise economics rewarded fewer, larger accounts and patient implementation. VA Software controlled both surfaces for a time, but it never made their incentives identical.

The free forge was a bundle of powers

SourceForge.net is often remembered as a repository host. That description is too narrow. At launch in early 2000, the service offered project web space, source control, communications and access controls through a browser. A contemporaneous reproduction of VA’s launch announcement reported roughly 700 projects and 3,000 developers; six months later, a VA release claimed more than 6,000 projects and 40,000 registered users. The figures are company claims, not audited usage measures, but the service’s rapid adoption is independently consistent with its later prominence.

The important unit was not the repository. It was the project. A project could have a name, a public page, membership, release files, a bug tracker, patch and task records, documentation, forums, mailing lists, news and statistics. Users could search across projects and decide where to contribute. Maintainers could make releases available without running their own download infrastructure. A project’s presence on the site therefore accumulated several forms of capital at once: a stable address, discoverability, contributor history, issue knowledge, audience attention and visible activity.

Control over that bundle gave VA Software several distinct powers. It set the project-registration and acceptable-use rules. It decided which features received engineering attention. It operated the accounts through which people joined projects. It controlled the download mirrors and the measurements shown to maintainers. It determined how projects appeared in site search and categories. Through the surrounding Open Source Development Network properties—including Slashdot, Linux.com and Freshmeat—it also sat close to the channels through which technical news and software releases gained attention. VA’s historical company page described the network as a large audience for technology marketers. The page is now a legacy artefact on a domain whose present condition makes it unsuitable as sole evidence; its historical claims are useful only where filings and dated reporting corroborate them.

This control was partly infrastructural and partly social. Hosting servers, storage, databases and bandwidth was expensive, especially when a popular release could produce a sudden surge in downloads. VA said in 2002 that SourceForge.net had moved to IBM DB2 and was serving 3.2 million page views a day across 45,000 projects and 460,000 registered users. That migration announcement was also marketing for IBM, so its performance language should be read as a joint claim. Still, it shows the operational problem: the free forge had become a shared service whose failure or neglect could affect thousands of unrelated projects at once.

The social power appeared when small features stopped working. In a 2007 retrospective based on interviews with maintainers and former staff, Datamation reported that SourceForge.net had been thinly staffed in the middle of the decade. The founder of Audacity recalled slow source-control access and basic breakage; a Gallery developer said download statistics could remain broken for long periods. Statistics mattered because maintainers used them to demonstrate reach to contributors, employers and sponsors. The report described those numbers as a form of currency. A counter on a free website could thus influence a project’s standing even though no contractual service level protected it.

VA did not control the open-source code hosted on the site merely by hosting it. Licences, contributor arrangements and project leadership remained project-specific. Nor did it own every discussion or decide every release. Its power was more conditional and, in some ways, more modern: it controlled the environment in which many independent decisions became legible and useful. Maintainers could leave, but leaving meant reconstructing more than a source tree. The service’s convenience was a network of dependencies.

That distinction explains why community trust was economically valuable. The public service filled with useful projects because maintainers believed it was worth investing their time there. Their work attracted downloaders and readers; that attention supported advertising across VA’s media properties. The company paid the infrastructure bill and made coordination easier, while the community supplied most of the software, discussion and reasons to visit. Neither side was simply donating to the other. They were exchanging different things without a conventional price attached to each exchange.

From reference implementation to proprietary governance

VA’s first attempt to carry the public forge into a paid setting was SourceForge OnSite. Announced in December 2000, it was offered as a subscription installed behind a customer’s firewall and customised, implemented and supported by VA. The launch release named Agilent Technologies as the first customer and listed source control, bugs, patches, tasks, documents, communications and project statistics among the functions. The public site, then said to host 12,000 projects and 92,000 users, served as proof of demand for the workflow.

That origin created a tempting story: open-source collaboration had discovered a better way to build software, and large organisations would pay to bring the same way of working inside. In June 2001, as VA exited the hardware business and cut roughly 35 per cent of a 436-person workforce, the company said it would concentrate on SourceForge OnSite. It called SourceForge.net a “reference implementation” and expected enterprise software to become the majority of revenue. The strategy announcement is evidence of management’s intention, not proof that the expected revenue shift occurred.

The product soon became SourceForge Enterprise Edition, or SFEE. Its purpose was not simply to clone a public website onto a private server. VA increasingly presented it as a management system for the software lifecycle. A 2001 release for version 3.0 emphasised search, monitoring, reporting, document versioning, issue workflow and integration with Oracle. Later releases connected corporate directories, existing source-control systems, Microsoft Project and Office, and development environments. By version 4.1, VA Linux Systems Japan said the application had been rewritten on J2EE and exposed an SDK and SOAP interface. The Japanese release description is a primary reseller statement rather than an independent technical assessment, but it helps establish that the enterprise product had become its own codebase.

That separation is crucial. Community criticism sometimes described VA as taking SourceForge closed. At the level of platform governance, the criticism had force: the software used to develop the public service ceased to be released under a free licence after 2001. LWN’s contemporary account dated the last free SourceForge release to November of that year and traced the resulting GForge and Savannah forks. Yet by the later VA Software period, SFEE was not simply the same application running SourceForge.net with a licence switched. Reporting around the 2007 sale said the public site did not run the enterprise product, and CollabNet later described the commercial application as a rewrite. The shared name communicated lineage and credibility more than identical machinery.

What moved from public to private was therefore a pattern of work. Give every project a persistent home. Put code, issues, documents and discussion within reach of the same account system. Associate a commit with the task or defect it addresses. Let a manager see activity across projects rather than requesting separate status reports. Preserve enough history to reconstruct why a change occurred. In a public community, those functions lowered the cost of voluntary coordination. In an enterprise, they could become mechanisms of oversight.

That change of purpose affected the governance bargain. A public maintainer could create or join a project and use the service without persuading a procurement department. An enterprise deployment needed executive sponsorship, system administration, identity integration, role design, migration and training. Public openness favoured broad visibility; corporate adoption demanded confidential projects and differentiated permissions. Community norms tolerated heterogeneous processes; management buyers often wanted common reports and enforceable transitions.

SFEE was valuable to the extent that it made this translation possible without forcing every team into an entirely new source-control tool.

The company could credibly say it had observed collaboration at scale. It could not automatically infer that public popularity proved enterprise suitability. The public service tested traffic and voluntary use, not a bank’s access-control policy, a manufacturer’s change process or a government buyer’s records requirements. VA’s commercial opportunity lay in the gap between those worlds. Its risk was that bridging the gap required expensive sales, consulting and support that free-site growth did not demonstrate.

What an enterprise buyer actually installed

The most revealing description of SFEE is not a launch speech but the company’s 440-page version 4.3 SP1 user guide, dated September 2006. It depicts a central web application used by developers, project managers, project administrators and site administrators. Projects contain applications for tracking work, documents, tasks, discussions, wikis and source code. The system integrates with CVS, Subversion and Perforce rather than requiring every customer to put code in a new proprietary repository. It can connect to a corporate LDAP directory and assign access through project membership and roles.

For an ordinary developer, the appeal was context. A commit could be associated with a tracker item, task or document. A defect could carry comments, attachments, dependencies and a history of status changes. A document could pass through review while preserving versions. Forums, mailing lists and wikis kept discussion near the work. Search reduced the need to know which silo contained the answer. This was especially useful in distributed organisations, where the alternative might be a mixture of email, shared drives, spreadsheets and unrelated issue trackers.

For a manager, the value was visibility. Reports could aggregate activity, although the guide says results were filtered by the viewer’s permissions. Tasks could be arranged into hierarchies and synchronised with Microsoft Project. Tracker workflows could restrict who moved an item from one status to another and require a comment or attachment at a transition. A central application made it possible to compare projects and see delays without asking every team to assemble a bespoke report. VA’s public product material described that as improved control and resource management.

Those are vendor claims; the guide proves the functions existed, not that they improved delivery in every organisation.

For an administrator, the product created a substantial design job. Roles were cumulative: a user’s permissions could come from several roles. Permissions could be assigned to applications and folders, with documented limits on finer-grained inheritance. Project membership could require approval. Administrators could define tracker fields and workflows, connect repositories, control forums and configure integrations. These choices encoded the organisation’s development policy. A poor role design could expose confidential work or block legitimate contributors; an over-elaborate workflow could turn traceability into delay.

Implementation was therefore part technical integration and part institutional negotiation. A buyer had to decide which projects belonged in the system, who could create them, how teams mapped to directory groups, which tracker states counted as approval and which existing records should be moved. It had to connect source-control servers and test whether links between code and work items survived daily use. If Microsoft Project was used, the guide warned about synchronisation journals and described circumstances in which a missing journal could cause errors or data loss.

A feature advertised as integration still required disciplined operation.

VA sold professional services for installation, integration, process consulting and training. Its 2006 annual report said these services were generally billed on a time-and-materials basis. The company maintained that customers could use the software without them, but the breadth of the guide and the integration surface explain why larger deployments might buy help. The same filing described direct field and telephone sales, maintenance, support and optional hosting through a third party.

Deployment location changed the risk, not the need for trust. An on-premises installation kept source code and project records behind the customer’s firewall, a strong answer to organisations unwilling to put confidential development on the public internet. A hosted option transferred more operational responsibility to VA and its infrastructure provider. In both cases, the customer depended on VA for fixes, upgrades and product knowledge. On-premises control protected against a public service outage, but it did not make the proprietary application maintain itself.

Version 4.3 added wikis, configurable tracker workflows, email interaction and single sign-on for external applications. InfoWorld reported that buyers could run it behind the firewall or use a hosted service, and cited a price of $2,725 per user. That price made the target clear. SFEE was not a cheap replacement for a small team’s bug tracker; it was sold as a common operating layer whose cost could be justified when coordination failures, duplicate tools and weak visibility were expensive.

The architecture also reveals the product’s switching costs. Code could remain in CVS, Subversion or Perforce, reducing one form of capture. Tracker reports and artefacts could be exported in common formats. But the useful whole included role definitions, workflow rules, cross-links among commits and issues, document histories, discussions, wiki versions, task structures, reporting conventions and user habits. The guide documents exports for parts of that whole; it does not demonstrate a single, lossless export of an entire deployment into a competing system.

The customer owned more of the infrastructure than a SourceForge.net maintainer did, yet could still become dependent on the organising layer.

The economics of selling control

VA Software asked two different constituencies to pay in different currencies. An enterprise buyer paid licence fees, renewable maintenance, hosting fees when applicable and professional-services charges. A public project paid mostly through participation: its releases and conversations attracted users, search traffic and page views that VA could sell to advertisers. The surrounding media properties amplified that attention, while ThinkGeek converted a related audience into commerce.

The enterprise side showed genuine growth. According to the 2006 annual filing, software revenue rose from $4.995 million in fiscal 2004 to $7.555 million in 2005 and $9.974 million in 2006. The aggregate customer count increased from 97 to 130 to 164, while average contract value rose from about $75,000 to $106,000 and then $129,000. VA attributed the 2006 increase across licence, maintenance, hosting and professional-services revenue rather than to a single component.

Those numbers confirm that organisations bought the product. They do not show an efficient standalone software business. The same filing recorded a software-segment operating loss of about $2.7 million in fiscal 2006, after a loss of roughly $5.4 million the previous year. About $3.2 million, or 51 per cent, of company research-and-development spending that year was allocated to SFEE. Sales cycles commonly exceeded three months and could run beyond a year. Prospective customers considered implementation time, compatibility and total cost, and large buyers expected support and volume pricing.

The list price and the average contract value illuminate the sales logic. At $2,725 per user, a broad rollout could become expensive quickly. A negotiated enterprise agreement could combine seats with maintenance, hosting and services, so the filing’s average contract value is not a simple multiplication of users by list price. Still, the economics favoured accounts large enough to value cross-project governance. Each deal could be meaningful, but it required specialised sellers, demonstrations, security discussions, integration work and continued support.

The product could grow revenue while consuming more organisational effort than a browser-based tool’s gross margin suggested.

Maintenance was central to the bargain. VA described annual renewable maintenance priced as a percentage of the product licence, including support and unspecified upgrades. Periodic bug and security fixes were part of the vendor relationship. A perpetual right to run a version did not provide a practical way to operate indefinitely without expertise, compatibility work and patches. That made recurring revenue possible and also made the buyer attentive to the vendor’s durability.

The public side had the opposite scaling pattern. One improvement to project hosting could benefit many projects; one additional page view could add advertising inventory at little incremental sales cost. But traffic was not free to serve, and the people creating the value were not employees. Underfund the service and maintainers would experience slow repositories, broken statistics and neglected features. Monetise too aggressively and they could conclude that their work was being used to build an audience over which they had little say.

By fiscal 2006, online media and commerce were not peripheral. The filing reported $13.242 million of online-media revenue and $20.416 million from e-commerce, compared with $9.974 million from software. A Motley Fool analysis credited the company’s first profitable full year largely to strong online-media advertising growth. That interpretation came from an investment publication, but it is consistent with the segment figures. The more scalable business was becoming the audience, not the enterprise control room.

This did not mean SourceForge.net was merely an advertisement page. Its utility created the audience, and its brand helped sell the enterprise system. Yet the financial centre of gravity mattered when management allocated capital. Improving a free developer service protected trust and traffic. Building SFEE 4.x, supporting integrations and pursuing long enterprise sales protected software revenue. Both activities competed for engineers and attention. The company’s eventual choice—to sell the enterprise operation and keep the media and commerce assets—followed the stronger economics.

There was an additional subtlety: SourceForge.net acted as both public infrastructure and a demonstration. VA could point to a vast, active service when selling collaboration software, even though the enterprise application was separate. That reputational transfer lowered the cost of explaining the product. But it could also blur accountability. Success at operating an open project community did not prove a specific enterprise deployment would meet a buyer’s controls; an enterprise licence did not fund a guaranteed level of service for every public maintainer. The shared name bundled credibility more readily than obligations.

Trust was the scarce input

The decisive conflict arrived when VA stopped releasing new versions of the SourceForge platform under a free-software licence. From the company’s perspective, proprietary enterprise code protected an investment and supported licence revenue. Forbes reported in 2005 that VA executives feared an open release would enable competitors to make near copies and damage sales. That position was commercially intelligible: if the product’s main advantage could be reproduced without paying VA, recovering the cost of its development and support would be harder.

From the community’s perspective, the change altered the insurance embedded in openness. A hosted service is easier to trust when users can reproduce the software, move it or support a credible alternative. In October 2001, free-software advocate Loïc Dachary argued that SourceForge users could retrieve source code and tracker data but not a complete project, and criticised the site’s terms and VA’s control over the surrounding infrastructure. His FSFE-published essay is an advocacy source and includes contested interpretation, not a neutral audit. Its importance lies in showing what technically sophisticated users believed they were losing: not the right to their code, but a practical exit from the whole collaboration environment.

The response was not only rhetorical. GForge and GNU Savannah developed from the last free SourceForge code. LWN documented the forks and the gap between the proprietary product and the public site. The forks reduced VA’s exclusive control over the idea of a forge. They also demonstrated that code availability alone did not recreate SourceForge.net’s accumulated project directory, accounts, traffic or media reach. Software could fork more easily than a community’s address and history.

This was the centre of the governance bargain. VA provided real resources: machines, bandwidth, operations, product development and a convenient shared workflow. It had a legitimate need to finance them. Maintainers provided real resources too: software, documentation, support conversations, attention and reputation. Their work made the site useful to other users and valuable to advertisers. Because no invoice captured that contribution, management could mistake free usage for demand that belonged to the platform rather than trust temporarily entrusted to it.

The Datamation retrospective makes the cost of that mistake concrete. During a period of limited investment, project leaders reported broken or slow services, while SourceForge.net reportedly had only a handful of staff. In 2006, after the site became profitable, staffing and infrastructure improved; Subversion support, monitoring and search received attention. The account relies on interviews and should not be treated as a complete operational record. It nevertheless reveals an incentive loop.

Advertising depended on traffic; traffic depended on projects; projects depended on service quality; service quality depended on management choosing to reinvest in people who did not directly pay.

Enterprise trust worked differently. A customer had a contract, a support channel and software it could run on its own premises. It could negotiate pricing and, at sufficient scale, influence a roadmap. But it could not inspect and modify the full product under a free licence. Its leverage came from procurement, maintenance renewal and the cost to VA of losing a reference account. The customer’s protection was commercial rather than communal.

The two trust systems sometimes reinforced each other. Public scale gave enterprise buyers confidence that VA understood distributed development. Paying customers funded product expertise that could inform the broader organisation. They also sometimes conflicted. Features needed by a regulated enterprise did not necessarily help a volunteer project. Public openness could expose methods the company wanted to sell. Engineers assigned to a licence release were not improving the hosted site. The brand implied a common mission while the operating choices required prioritisation.

There is no need to portray VA as either a benefactor betrayed by ungrateful users or an extractor exploiting volunteers. Both caricatures miss the exchange. The company built a service that removed substantial friction from open-source work. Maintainers made that service strategically valuable. The failure was not that one side received value; it was that the rights and exit options governing the exchange were less developed than the dependencies that grew around it.

Dependency appeared in different forms

SourceForge.net was an early cloud dependency before that phrase became standard. A maintainer did not need to buy servers, configure source control, administer mailing lists, mirror downloads or build a project website. The service converted capital and administration into a URL and an account. That was liberating, particularly for small projects. It also concentrated failure.

The most portable component was usually source code. CVS and later Subversion were established tools, and a project could make another copy of a repository. The less portable components were context and coordination: tracker history, account membership, mailing-list archives, forum discussions, release statistics, inbound links, search rank and the expectation that users would find the next version at the same place. A technically successful migration could still lose contributors or strand old links. Dachary’s 2001 critique alleged that the service lacked a complete project export.

The later user reports about broken statistics show why seemingly peripheral metadata could matter.

The enterprise product reversed some of those risks. On-premises deployment gave a customer control over servers, network access and backups. Integration with existing repositories meant the source itself did not have to be trapped inside a novel store. Corporate LDAP could keep account authority with the customer. These were meaningful reductions in hosted-service dependence.

But centralisation created a new concentration. Once teams linked commits, issues, documents, tasks, discussions and reports through SFEE, the application became a map of how work moved. Managers learned to rely on its reports; administrators encoded approval rules; users learned its fields and transitions. Replacing it meant not only installing a competitor but deciding which history and policy to carry forward. Exporting a tracker table did not recreate its links to source changes or its role-dependent workflow.

Optional hosting added another layer. A hosted enterprise customer could avoid operations but depended on VA and a third-party host for availability and recovery. The public filings describe hosting revenue, not detailed service commitments or performance history. It would be unsafe to infer strong availability guarantees from the existence of a hosting option. A careful buyer would have needed to inspect the contract, backup arrangements and exit process.

The lesson is that location and licence answer different questions. Software behind a firewall can still produce vendor dependence. A free public service can host freely licensed code while keeping the surrounding workflow difficult to move. Open repositories reduce one switching cost; open standards and usable exports reduce others; a credible migration drill is what tests the whole. VA Software’s two SourceForges make those distinctions unusually visible.

Security, compliance and the limits of the record

VA sold SFEE partly on the difference between public collaboration and controlled collaboration. A company could place confidential projects behind its firewall, authenticate users against a corporate directory and give roles different permissions. Tracker workflows could require evidence at a status transition. Version histories and associations among issues, documents and commits could make development activity easier to reconstruct. VA’s product material used the language of auditability, traceability and visibility.

Those capabilities could support a control programme, but they were not the same as proving compliance. A required attachment can help document an approval; it does not establish that the approver was independent or that the underlying test was adequate. A history can reveal what the application recorded; it cannot capture decisions that occurred in email or a meeting unless users enter them. Role-based access can express policy; a misconfigured role can undermine it.

The user guide shows some important edges. Permissions were cumulative across roles. Reports respected the viewer’s permissions. Project administrators could govern membership and application access. The granularity had limits, including how folder permissions applied. Those details matter more to a buyer than a broad promise of “security” because they determine whether the product can represent the organisation’s separation of duties.

Public evidence does not support a stronger claim about the VA-era product. The reviewed filings, guide, releases and independent reports do not provide a complete third-party security assessment, a detailed availability history, recovery objectives or a comprehensive list of certifications for SFEE. Absence from this evidence set does not prove that no customer received such material under confidentiality. It means a reader should distinguish a product’s security features from independently verified security assurance.

The same caution applies to SourceForge.net. VA’s DB2 announcement demonstrates investment in scale, not a contractual guarantee to free projects. The site carried public code, but accounts, release files and project administration still required protection. A major compromise disclosed by SourceForge in 2011 affected infrastructure descended from the service, years after VA Software had changed its name and after management had shifted. The successor operator’s incident report is useful evidence of the class of risk created by a shared forge; it is not evidence of a VA-era breach and should not be assigned backward to VA.

For an enterprise buyer in 2006, the practical security test would have been architectural and operational. Which components were exposed to the internet? Where did credentials reside? Could LDAP groups be mapped without granting excessive permissions? How were patches delivered and tested? What did the third-party hosting arrangement cover? Could administrators export logs and demonstrate that a change passed the required states? VA offered features relevant to those questions. The public record does not answer all of them.

That evidentiary limit is itself part of the company’s history. SFEE was sold when enterprise software marketing often relied on firewall deployment and access control as shorthand for safety. The product may have been strong or weak in areas the surviving public documents do not show. A serious assessment must resist filling the gaps with either nostalgia or contemporary expectations.

Competition was a procurement decision, not a feature checklist

VA’s annual filings named a broad competitive field: CollabNet, IBM, Microsoft, Borland, Serena and customers’ own collections of commercial, open-source and home-grown tools. Those alternatives did not all sell the same thing. A buyer comparing them was deciding how much of the development process to centralise, which existing repositories to preserve, whose support to trust and how much process change the organisation could absorb.

The incumbent was often not another suite. It was email plus shared drives, a source-control server, spreadsheets, a bug tracker and the knowledge held by experienced employees. That arrangement could be cheap in licence terms and expensive in coordination. It allowed teams to choose their tools but made portfolio reporting and cross-team search difficult. SFEE’s strongest case was not that every component was unique; it was that the components shared users, permissions and associations.

Open-source alternatives such as GForge and Savannah changed the licence comparison. An organisation with engineering capacity could run a descendant of the earlier SourceForge code and retain more freedom to modify it. The trade-off was responsibility: integration, upgrades, security fixes and support would fall to the organisation or another supplier. The presence of a fork also did not guarantee feature parity with SFEE’s later J2EE application, enterprise directory support or vendor integrations.

Large platform vendors offered different leverage. IBM and Microsoft could connect collaboration to wider development portfolios and account relationships. Borland and Serena brought established configuration-management products. CollabNet came from collaborative development and Subversion. VA countered with the SourceForge name, observed public-community workflow and an application designed to sit above several repository choices. Its openness at the integration boundary was strategically important even though the product itself was proprietary.

CollabNet’s eventual role as buyer is telling. A contemporary InformationWeek report said VA had roughly 200 enterprise customers and CollabNet about 100, while SourceForge.net itself had approximately 146,768 projects and 1.6 million registered users. Those figures were reported around the transaction and may use company definitions, but they show why the deal was more than a code purchase. CollabNet acquired customer relationships, a team and a familiar enterprise product from a former rival.

A prudent procurement team would therefore have tested five propositions rather than counting wiki and tracker features. First, could the suite represent the organisation’s real approval and access rules without excessive customisation? Second, did its integrations preserve existing repositories and planning practices or merely add another screen? Third, could a representative project be migrated in and out with its useful history intact? Fourth, did the vendor have the financial incentive and staff to sustain the product? Fifth, what happened to support after a change of control?

VA could answer the first two with demonstrations and a pilot. The guide and product releases show substantial breadth. The third required an export exercise; public documentation supports partial exports but not a complete portability claim. The fourth was increasingly uncomfortable because software revenue growth had not eliminated the segment’s losses. The fifth became real in 2007. Procurement was not merely choosing the best feature set. It was choosing a governance counterparty.

Why the software business was sold

The sale to CollabNet was not an abrupt admission that nobody wanted SFEE. The product had a growing customer count, rising average contract value and recognisable buyers. VA reported repeat purchases from organisations including FedEx, Lockheed Martin and the US Forest Service, while naming new customers in industrial, technology and public-sector markets. Such announcements prove commercial transactions, not adoption depth or customer outcomes, but they contradict the idea of a product with no market.

The problem was the shape of the market relative to VA’s other assets. Enterprise collaboration required sustained product investment, specialised support and lengthy selling. Online media and e-commerce were larger revenue contributors by fiscal 2006, and advertising was growing quickly. Management could keep financing a subscale software competitor or concentrate on audience and commerce.

The 2007 amended annual report records the choice in accounting terms. VA transferred substantially all software-business assets and certain liabilities to CollabNet in exchange for 11,733,777 shares of CollabNet preferred stock, valued at about $6.6 million at closing. It recorded a gain of roughly $5.7 million before tax. The deal included intellectual property and equipment; CollabNet offered employment to transferred staff, while other employees were terminated. VA emerged with an equity interest in the buyer rather than simply taking cash and walking away.

The agreement also preserved a bridge between the businesses. Reporting said VA would advertise CollabNet and forward enterprise prospects for 30 months. The SourceForge brand and public audience could continue to generate leads even though CollabNet now owned the product. That arrangement recognised the commercial connection without pretending the products were one system.

Financial history gives the decision more force. The amended filing reports software revenue of $7.555 million in fiscal 2005, $9.974 million in 2006 and $5.236 million in the partial 2007 period before the sale, alongside operating losses in each period. The exact period comparisons require care because the final year was truncated. The direction is nonetheless clear: VA had built a real enterprise business, but it had not demonstrated durable segment profitability before disposal.

After the sale, the original corporation stopped needing “Software” in its name. On 24 May 2007 it became SourceForge, Inc. and merged the operations of its media subsidiary into the parent. Computerworld’s report described a company focused on web properties, advertising and ThinkGeek. The rename was not cosmetic. It acknowledged that the public brand and its audience, not the enterprise application, defined the remaining business.

VA Software’s strategy can therefore be read as an experiment with three conversions. It tried to convert public collaboration practice into enterprise software, community attention into advertising revenue and technical audience affinity into commerce. The first produced a valuable asset but an expensive independent business. The second and third better matched the company that remained. Selling SFEE separated the conversion that required enterprise operating depth from those that benefited most from audience scale.

What customers, maintainers and owners inherited

The transaction created at least four inheritances, each with a different relationship to VA Software.

Enterprise customers inherited CollabNet as the product’s steward. The transfer included the relevant development, support, sales and field-services operation, reducing the risk of a purchase stripped from the people who understood it. In Japan, VA Linux Systems Japan announced that it would continue selling and supporting the product after the transfer. Two years later, CollabNet renamed SourceForge Enterprise Edition as TeamForge, partly to remove confusion with SourceForge.net. InternetNews reported that the product was then presented as CollabNet TeamForge. The rename clarified what the 2007 sale had already established: the enterprise lineage no longer belonged to the public site’s owner.

Public maintainers inherited continuity of service under SourceForge, Inc., not CollabNet. Their project URLs, repositories, releases and communities stayed with the original corporate operator. That continuity avoided a forced migration at the moment of sale. It also meant that maintainers did not follow the enterprise engineers and support organisation merely because both had once used the SourceForge name.

Open-source forge operators inherited the earlier free code and the argument for independence. GForge and Savannah had already shown that a community could build another forge from the last freely released platform. They did not inherit SourceForge.net’s traffic, project directory or brand. Their existence nonetheless gave organisations and projects an alternative governance path, and it preserved the idea that the collaboration layer itself could be inspectable and modifiable.

The original corporation inherited the audience and the problem of monetising it. It became Geeknet in November 2009. In 2012, Geeknet sold the media business that included SourceForge, Slashdot and Freecode to Dice Holdings for $20 million in cash, according to a later SEC filing. In 2016, the SourceForge and Slashdot properties changed hands again; the SourceForge team said BIZX had acquired them and promised to end a controversial installer programme. Those later decisions belong to successor owners, not VA Software. They demonstrate why brand continuity cannot substitute for corporate identity.

The current SourceForge site still presents itself as a large software discovery and hosting platform. Its public homepage claims hundreds of thousands of projects and millions of registered users under the Slashdot Media name. Those contemporary claims are not evidence of VA’s current operations; VA Software no longer exists under the assigned name. They show that the public asset outlived the particular bargain that created it.

The product lineage also outlived the sale. TeamForge documentation remains available through later enterprise-software stewardship. Survival does not prove that every VA-era customer stayed, nor that old workflows migrated without friction. It does show that CollabNet did not buy a product merely to close it immediately. Customers received a continuing commercial path, while maintainers received a continuing hosted path. The paths diverged.

This split answers the qualification question more precisely than a list of acquisitions. VA controlled a public community environment, an enterprise product, media properties and a commercial relationship among them. It did not own the independent projects’ software simply because it hosted them. When the assets separated, customers inherited product continuity from the buyer; maintainers inherited service continuity from the renamed seller; later owners inherited the audience, archives and monetisation tensions.

A procurement test for the bargain

VA Software is historical, but its two control surfaces provide a demanding test for any present-day developer platform. The test begins by refusing to ask only, “Where is the code?”

Map the entire project, not the repository. A buyer or maintainer should inventory issues, discussions, release files, documentation, package links, accounts, permissions, webhooks, statistics and inbound addresses. SourceForge’s history shows that download counts and project discovery can be operational assets even when they look like website decoration. A repository mirror protects the code but may not protect the project.

Separate operator control from project ownership. An open-source licence can guarantee rights in code while the platform retains authority over accounts, ranking, acceptable use, advertising and availability. The relevant questions are who can suspend a project, change a URL, alter a download page or modify access policy, and what appeal exists. VA’s public users owned or licensed their work under project-specific terms; VA still controlled the environment through which much of that work reached users.

Run an exit before dependence is complete. SFEE could export tracker artefacts and reports, and it integrated with established repositories. Those were useful safeguards. A serious test would also reconstruct roles, workflow states, links, document histories and discussions in another system, then measure what was lost. For a hosted community, the drill would include redirects, release mirrors, mailing-list archives and a way to notify users. Portability is an observed result, not a checkbox labelled “export”.

Price the operating relationship, not the initial licence. VA’s filings divide software revenue among licences, maintenance, hosting and services, while its guide exposes the administrative work of role and workflow design. Total cost included seller time, buyer time, integration, training, upgrades and the disruption of standardising teams. The same logic applies to a free public service: the invoice may be zero, but migration and outage costs are not.

Test control claims against real permissions. A pilot should use representative confidential projects and actual job roles. Can a contractor see only the intended applications? Do cumulative roles grant unexpected rights? Does a manager’s report omit records the manager cannot access? Can a required approval be bypassed through another route? VA’s documentation was specific enough to make such tests possible; marketing language alone was not.

Demand evidence for availability and recovery. SourceForge.net’s scale claims and DB2 migration indicated engineering investment, but free users did not thereby receive a service guarantee. Hosted enterprise buyers needed contract terms, backup responsibilities, recovery objectives and a tested data-return process. On-premises buyers needed patch delivery and upgrade procedures. “Behind the firewall” answered where the server sat, not how the service recovered.

Examine the operator’s portfolio incentives. VA had to choose among the public forge, enterprise product, media sites and commerce. By 2006, the latter businesses were financially powerful. A customer should ask which line funds the platform, which line competes for its engineers and whether user activity is also advertising inventory. Cross-subsidy can make a service possible; it can also make its priorities hard to read.

Write for a change of control. The 2007 transfer was relatively orderly because product assets and many employees moved together, and a referral arrangement connected the old and new owners. Even so, customers faced a new counterparty and maintainers remained with a different company. Contracts should address assignment, support continuity, access to data, notice, transition assistance and the fate of prepaid maintenance. Community projects without contracts need their own contingency plan.

Distinguish a shared name from a shared system. VA’s most persistent source of confusion was branding. SourceForge.net, SFEE, OSDN media properties, SourceForge, Inc. and later owners were related, but not interchangeable. A procurement record should identify the legal supplier, deployment, product version, support provider and data operator. Brand familiarity is not provenance.

These tests are not an argument against hosted tools or integrated suites. SourceForge.net enabled projects that might not have afforded reliable infrastructure, while SFEE helped organisations connect fragmented development work. The tests are an argument for matching convenience with governance. Dependency becomes dangerous when it grows faster than the evidence about exit, control and incentives.

The company’s lasting lesson is the split

VA Software did not fail to find value in open-source workflow. It found several kinds of value and discovered that they belonged to different businesses. The public forge made projects easier to create and find. Its community and surrounding media network assembled an audience that advertisers wanted. The enterprise product translated project collaboration into permissions, reporting, integration and paid support. ThinkGeek monetised affinity through goods. Each conversion worked to some degree; they did not all fit comfortably inside one operating structure.

The company’s most consequential power was the ability to define the place where software work became coordinated and visible. On SourceForge.net, that meant project identity, discovery, downloads and community history. In SFEE, it meant roles, workflows, cross-links and management reporting. One control surface depended on voluntary trust; the other sold contractual control. Both became more valuable as users placed more of their working context inside them.

The revenue bargain tested that trust. Closing development of the forge platform protected a proprietary enterprise asset but weakened the community’s assurance that it could reproduce the service. Advertising financed public infrastructure but made attention a corporate asset. Enterprise maintenance funded support but increased customers’ concern about vendor continuity. None of those choices was irrational. Together they made the shared SourceForge name carry expectations that one company could no longer reconcile.

The 2007 sale resolved the contradiction by distributing the pieces. CollabNet took the enterprise software and much of the organisation that served its customers. The renamed SourceForge, Inc. kept the hosted community, media traffic and commerce. Forks carried forward the last free platform code. Later owners acquired the public brand and its accumulated audience. No successor inherited the whole bargain.

That is why VA Software remains useful to study. Its story predates today’s dominant developer platforms, yet it exposes their central questions with unusual clarity. Who controls project identity and discovery? Which parts of a software community are portable? What does a free service receive in exchange for infrastructure? How does a proprietary workflow layer turn convenience into switching cost? And when an operator sells or renames itself, who inherits the obligations that users thought belonged to the brand?

The answer is never just “the code host”. It is the legal entity, the service, the product, the people who support it, the community that supplies its value and the agreements—or absences of agreement—that connect them. VA Software’s forge was powerful because it brought those elements together. Its history became legible when they came apart.